-
Notifications
You must be signed in to change notification settings - Fork 218
Add support for federated principal and role with block for manual role assignment #1353
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -38,19 +38,19 @@ public static PrincipalRoleEntity of(PolarisBaseEntity sourceEntity) { | |
public static PrincipalRoleEntity fromPrincipalRole(PrincipalRole principalRole) { | ||
return new Builder() | ||
.setName(principalRole.getName()) | ||
.setFederated(principalRole.getFederated()) | ||
.setProperties(principalRole.getProperties()) | ||
.build(); | ||
} | ||
|
||
public PrincipalRole asPrincipalRole() { | ||
PrincipalRole principalRole = | ||
new PrincipalRole( | ||
getName(), | ||
getPropertiesAsMap(), | ||
getCreateTimestamp(), | ||
getLastUpdateTimestamp(), | ||
getEntityVersion()); | ||
return principalRole; | ||
return new PrincipalRole( | ||
getName(), | ||
PolarisEntity.isFederated(this), | ||
collado-mike marked this conversation as resolved.
Show resolved
Hide resolved
|
||
getPropertiesAsMap(), | ||
getCreateTimestamp(), | ||
getLastUpdateTimestamp(), | ||
getEntityVersion()); | ||
} | ||
|
||
public static class Builder extends PolarisEntity.BaseBuilder<PrincipalRoleEntity, Builder> { | ||
|
@@ -65,6 +65,13 @@ public Builder(PrincipalRoleEntity original) { | |
super(original); | ||
} | ||
|
||
public Builder setFederated(Boolean isFederated) { | ||
if (isFederated != null && isFederated) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This logic doesn't look right to me. This entity would come out federated:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, the idea is to avoid adding any entry for non-federated identities. I don't think the logic snippet you posted is reasonable or should be supported. I'd be in favor of an IllegalStateException if someone typed that code. Happy to add that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why should it not be supported? It sounds like you're saying that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm saying the code example you suggested is a programming error. Ideally, that would be handled by the compiler, but an exception would also work. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I support @eric-maynard 's point here. Current code is very risky in terms of latent bugs, IMHO. A caller of |
||
internalProperties.put(PolarisEntityConstants.FEDERATED_ENTITY, "true"); | ||
} | ||
return this; | ||
} | ||
|
||
@Override | ||
public PrincipalRoleEntity build() { | ||
return new PrincipalRoleEntity(buildBase()); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given how different the semantics for federated principal (role)s appear to be, I wonder if we should consider a subtype? It looks like most APIs are valid for nonfederated principal (role)s are not valid for federated ones. This is reminiscent of EXTERNAL catalogs, but maybe more extreme
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
External catalog has a separate type because it has an extra field. Federated identity types don't have any additional fields at this point, so I'd prefer not to add an extra type. If extra fields end up getting added, then it would make sense, but for now deserializing wouldn't even be able to distinguish what type it should deserialized to.