Hi,
Preparing for JSR 375 presentations provides the opportunity for me to
step back and look at the big picture. I think I realized some things
that perhaps are obvious to some of you regarding application-based
group to role mapping. Please let me know if you agree with this
understanding.
=====
1. The proposed feature of One-To-One Group to Role mapping is far more
than a convenience. The feature takes the container out of the loop
regarding the Group-to-Role hierarchy, and delegates that mapping solely
to the application via JASPIC. That means, the application can define
caller-to-role mapping any way that the application requires, whether
via a Group of callers, or a hierarchy of Groups of callers, or some
other application-specific mapping. The only important part is that
IdentityStore returns the resolved list of "groups" after validating the
caller. I say "groups" because based on the existing JASPIC API, these
"roles" are still considered as "groups" from the JASPIC
GroupPrincipalCallback.
2. The proposed IdentityStore result CredentialValidationResult
https://github.com/javaee-security-spec/javaee-security-proposals/blob/master/identity-store-readonly/src/main/java/javax/security/identitystore/CredentialValidationResult.java
does not need the getCallerRoles method, since based on #1 above, the
getCallerGroups method would report the application-resolved roles
stored in the application-provided backend persistence store.
3. JASPIC GroupPrincipalCallback is good enough. At one point, I think
we proposed an additional RolePrincipalCallback to convey Group-To-Role
mapping via JASPIC. But based on #1 above, application-defined role
assignments could sufficiently be conveyed by the GroupPrincipalCallback.
4. To dynamically change a caller role while the application is running
(e.g., upgrade a user from "Basic" membership to "Premium" membership),
the application would have to do something like:
1) The application would have to update the application-managed
persistence store backing the IdentityStore (e.g., LDAP, DB) to assign
the updated roles to the caller.
2) The caller would have to logout and login to re-authenticate and get
new roles via the IdentityStore and applied to the container via JASPIC.
5. Embedded role mapping would simply be handled by the
EmbeddedIdentityStore. Embedded role mapping was originally proposed
using this annotation:
@EmbeddedRoleMapper( {
@RoleMap(user="foo",roles="admin"),
@RoleMap(group="admin",roles={"admin","manager"}) } )
public class MyServlet { }
But based on #1 above, the following annotation seems sufficient:
@EmbeddedIdentityStoreDefinition({
@Credentials(callerName = "reza", password = "secret1", groups = {
"foo", "bar" }),
@Credentials(callerName = "alex", password = "secret2", groups = {
"foo", "kaz" }),
@Credentials(callerName = "arjan", password = "secret3", groups = {
"foo" }) })
=====
Please let me know if you agree with this understanding. Based on the
above, the application-based role mapping is really just the
IdentityStore API + One-To-One group-to-role mapping + JASPIC. The
existing JASPIC callback handlers would be sufficient.
With regards,
Alex