UAA does not check for uniqueness of group names on user creation

[schmidtsv]

Hello UAA people,

we have found an undeletable user in our environment.

uaac user delete a9s-billing-2022 

CF::UAA::BadResponse: invalid response from /Users/680c9922-a6d0-4d36-8f72-590ce523761b: 422

We can trace back this behavior to at least 2021. After debugging I assume the error is caused here:

uaa/server/src/main/java/org/cloudfoundry/identity/uaa/scim/jdbc/JdbcScimGroupMembershipManager.java

Lines 317 to 384 in 262c761

	public ScimGroupMember removeMemberById(final String groupId, final String memberId, final String zoneId)
	throws ScimResourceNotFoundException, MemberNotFoundException {
	ScimGroupMember member = getMemberById(groupId, memberId, zoneId);
	int deleted = jdbcTemplate.update(DELETE_MEMBER_SQL, ps -> {
	ps.setString(2, groupId);
	ps.setString(1, memberId);
	ps.setString(3, zoneId);
	});
	if (deleted != 1) {
	throw new IncorrectResultSizeDataAccessException("unexpected number of members removed", 1, deleted);
	}
	return member;
	}
	@Override
	public List<ScimGroupMember> removeMembersByGroupId(final String groupId, final String zoneId) throws ScimResourceNotFoundException {
	List<ScimGroupMember> members = getMembers(groupId, false, zoneId);
	logger.debug("removing " + members + " members from group: " + groupId);
	int deleted = jdbcTemplate.update(DELETE_MEMBERS_IN_GROUP_SQL, ps -> {
	ps.setString(1, groupId);
	ps.setString(2, zoneId);
	});
	if (deleted != members.size()) {
	throw new IncorrectResultSizeDataAccessException("unexpected number of members removed", members.size(),
	deleted);
	}
	return members;
	}
	@Override
	public Set<ScimGroup> removeMembersByMemberId(final String memberId, final String zoneId) throws ScimResourceNotFoundException {
	Set<ScimGroup> groups = getGroupsWithMember(memberId, false, zoneId);
	logger.debug("removing " + memberId + " from groups: " + groups);
	int deleted;
	String sql = DELETE_MEMBER_IN_GROUPS_SQL_GROUP;
	if (isUser(memberId)) {
	sql = DELETE_MEMBER_IN_GROUPS_SQL_USER;
	}
	deleted = jdbcTemplate.update(sql, ps -> {
	ps.setString(1, memberId);
	ps.setString(2, zoneId);
	});
	int expectedDelete = isUser(memberId) ? groups.size() - getDefaultUserGroups(zoneId).size() : groups.size();
	if (deleted != expectedDelete) {
	throw new IncorrectResultSizeDataAccessException("unexpected number of members removed", expectedDelete,
	deleted);
	}
	return groups;
	}
	@Override
	public Set<ScimGroup> removeMembersByMemberId(final String memberId, final String origin, final String zoneId) throws ScimResourceNotFoundException {
	Set<ScimGroup> groups = getGroupsWithMember(memberId, false, zoneId);
	logger.debug("removing " + memberId + " from groups: " + groups);
	int deleted;
	deleted = jdbcTemplate.update(DELETE_MEMBER_WITH_ORIGIN_SQL, ps -> {
	ps.setString(1, memberId);
	ps.setString(2, origin);
	ps.setString(3, zoneId);
	});
	logger.debug("Deleted %s memberships for member %s".formatted(deleted, memberId));
	return groups;
	}

.
After further debugging it could be traced down to how the user was created in the uaa manifest.

We use the default default groups from the UAA release:
https://github.com/cloudfoundry/uaa-release/blob/develop/jobs/uaa/spec#L658-L673
On that specific user someone added scim.me and cloud_controller.read to the groups
- a9s-billing-2022|pw|a9s-billing-2022|||cloud_controller.admin_read_only,cloud_controller.read,scim.me,scim.read|uaa which then caused the user to be in scim.me and cloud_controller.read twice. Once implicit, once explicit.

My guess would be that on the code that creates the user either the check for duplicate membership is not executed, or does not see that user, or it does not check if the groups overlap with implicit groups. I can see 6 users in the cloud_controller.read group (assuming those are directly assigned users) and can see the group "cloud_controller.read" only once on the user object. If i remove it from both groups by hand, it will still show the group, but now the user can be deleted.

I do not know the best way to resolve this, my first guess would be on creation ignore the groups that overlap with the default groups, but that would cause problems if the user is not updated when default authorities are changed, but currently that behaviour creates users that need manual input to be deleted.

[strehle]

Hi, thanks for reporting. I need some help to reproduce it.

you have groups in uaa.yml and then you create groups via API correct ?

You mean you see in your UAA with
uaac group get cloud_controller.read
or
uaac group get scim.me

2 entries?