Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alias Handler for SCIM Users #2769

Merged
merged 31 commits into from
Jun 5, 2024
Merged

Conversation

adrianhoelzl-sap
Copy link
Contributor

@adrianhoelzl-sap adrianhoelzl-sap commented Mar 7, 2024

see issue #2505

Preparation for alias feature for SCIM users; adds subclass of EntityAliasHandler that handles alias entities of SCIM users.

Prerequisites:

@cf-gitbot
Copy link

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/187191383

The labels on this github issue will be updated when the story is started.

@adrianhoelzl-sap adrianhoelzl-sap added DO NOT MERGE Internal Test or WIP, please DO NOT MERGE and removed unscheduled labels Mar 7, 2024
@adrianhoelzl-sap adrianhoelzl-sap marked this pull request as ready for review April 11, 2024 15:31
@adrianhoelzl-sap adrianhoelzl-sap requested a review from a team April 11, 2024 15:43
@peterhaochen47
Copy link
Member

peterhaochen47 commented May 22, 2024

Hi, as this PR is a stepping stone toward the overall "alias feature," and as it looks like the changes are limited to the specific code paths related to the feature, I would defer the approval of this PR to @strehle, in terms of judging 1) whether this PR accomplishes its goal, and 2) wether this PR has enough test coverage and user docs (if applicable).

I'll also approve as well as long as our prior understanding the "alias feature" are still true after this PR: That the functionality & performance of all the existing UAA features are not impacted (do not experience breaking changes / regressions) when the "alias feature" is not turned on (and the feature is off by default).

Copy link
Contributor

@Tallicia Tallicia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with request to answer questions before merging.

final ScimUser existingAliasEntity
) {
// these three timestamps should not be overwritten by the timestamps of the original user
newAliasEntity.setPasswordLastModified(existingAliasEntity.getPasswordLastModified());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be setPasswordLastModifiedTime to align to the naming of the two following Time setters.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The setters are already named consistently to the underlying fields in the class as well as its JSON representation (passwordLastModified does not end with "time", lastLogonTime and previousLogonTime do), see for example here:

} else if ("passwordLastModified".equalsIgnoreCase(fieldName)) {

I would therefore suggest to leave them as they are. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems the naming inconsistency is more widespread, maybe this would be a good clean up following this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems the naming inconsistency is more widespread, maybe this would be a good clean up following this PR.

newAliasEntity.setPasswordLastModified(existingAliasEntity.getPasswordLastModified());
newAliasEntity.setLastLogonTime(existingAliasEntity.getLastLogonTime());
newAliasEntity.setPreviousLogonTime(existingAliasEntity.getPreviousLogonTime());
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these setting the Time to the existingAliasEntity instead of "now" or even null for the 2 logon times - a new Alias should have it's own timestamps. Setting them to the existingAlias seems it would be confusing when it was actually Modified or logged into.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is used for managing the fields that should differ between the "original" user and its alias, i.e., the properties of an alias that should be independent from the original user.

During updates, we build a copy of the original user and leave these three timestamps empty. After that, we call this method to overwrite the timestamps with the values from the version of the alias prior to the update.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which one is it,

"the properties of an alias that should be independent from the original user."

which I agree with
But this seems contrary to keeping them independent:

"After that, we call this method to overwrite the timestamps with the values from the version of the alias prior to the update."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the confusion in my explanation, I'll try again:

Let's say there is a user U in the "uaa" zone, which has an alias user A in the zone "custom". Whenever we perform an update on U, we persist the changes, which leads to a newer version U' with the changed properties.

Then, to propagate the changes also to the alias, we build a new clone of U', i.e., A'. This is done here:

protected ScimUser cloneEntity(final ScimUser originalEntity) {

However, as you correctly addressed, A' would now have the same timestamp values (last logon, password last modified and previous logon) as U', which is incorrect. Therefore, before persisting A', we look up the version of A' before the update, i.e., A, and overwrite the timestamp values of A' with the timestamp values of A.

This is done in the method of this GitHub conversation. The parameter newAliasEntity corresponds to A', while existingAliasEntity corresponds to A (and not to U or U', as you might have thought when asking the question).

@Tallicia Tallicia added in progress accepted Accepted the issue in_review The PR is currently in review clarification needed The issue is not accepted but we need clarification DO NOT MERGE Internal Test or WIP, please DO NOT MERGE labels May 29, 2024
Copy link
Member

@strehle strehle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see 100 coverage on lines at least. Coverage on all conditions might be hard, but we should have tests with a meaning on all code lines.

Tests are like a technical specification, they later help to understand the code

@strehle
Copy link
Member

strehle commented Jun 3, 2024

@strehle strehle removed the clarification needed The issue is not accepted but we need clarification label Jun 4, 2024
@Tallicia
Copy link
Contributor

Tallicia commented Jun 4, 2024

@strehle
Copy link
Member

strehle commented Jun 4, 2024

@adrianhoelzl-sap please cleanup PR , see https://sonarcloud.io/project/issues?resolved=false&sinceLeakPeriod=true&pullRequest=2769&id=cloudfoundry-identity-parent
Rest is ok

@strehle This link is not showing no results for me:

Screenshot 2024-06-04 at 9 11 40 AM

there where updates and now smells are solved
See overview https://sonarcloud.io/summary/new_code?id=cloudfoundry-identity-parent&pullRequest=2769

@strehle strehle removed in_review The PR is currently in review DO NOT MERGE Internal Test or WIP, please DO NOT MERGE labels Jun 4, 2024
@strehle
Copy link
Member

strehle commented Jun 4, 2024

@Tallicia do you have open issues here ?

@torsten-sap
Copy link
Contributor

I merge this PR as all questions seem to be addressed and two approvals exist.

@torsten-sap torsten-sap merged commit 3164d36 into develop Jun 5, 2024
20 checks passed
@torsten-sap torsten-sap deleted the feature/alias-handler-for-scim-users branch June 5, 2024 10:59
@cf-gitbot cf-gitbot removed in progress accepted Accepted the issue labels Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

None yet

6 participants