Hi Arjan,
Thanks for your comments! I just wanted to mention a subtlety. The
Identity Store proposal contains an SPI called an IdentityStore
interface, which is responsible for interacting with the persistence
mechanism. I think IdM or Identity Management system would really be a
better name for the proposal.
Please see inline.
With regards,
Alex
On 6/12/15 8:09 AM, arjan tijms wrote:
> p.s.
>
> My co-worker at zeef.com <http://zeef.com>, Jan Beernink, who worked
> on our security system too took a loot at the proposal document, and
> he had one additional comment:
>
> 6.
>
> Consider the following example code snippet:
>
> // Check credentials
> Credentials creds = new UsernamePasswordCredentials("john", new
> Password("welcome1"));
>
> identityManager.validateCredentials(creds);
>
> if (Status.VALID.equals(creds.getStatus())) {
> // authentication was successful
> }
>
> While the Credentials type is itself a nice idea (as opposed to an
> IdentityManager interface for each credential type), the fact that
> it's a mutable type that gets updated with a status is perhaps not
> entirely ideal.
>
> Why not have Credentials be a value type and just operate on the
> return value of validateCredentials()?
>
[Alex] After credential validation, the Credentials type returns both
the status of credential validation and the associated Account. The
status serves as a convenient result code to inform the caller why
validation failed. If the status is VALID, the Account is available. I
suppose the concern about mutability is that the caller and the
credential handling may be on different threads. Both Account and Status
could be assigned internally using volatile variables, so no locking
would be needed although there is a slight performance hit as shared
memory is resolved. So I do not see a big problem. Do you have a
specific use case?
I suppose we could do something like:
*
public interface Credentials {
void invalidate();
}*
*
public interface CredentialsValidationResult {
public enum Status {
UNVALIDATED, // Yet to be validated
IN_PROGRESS, // In the process of being validated
INVALID, // Validated unsuccessfully
VALID, // Validated successfully
EXPIRED // Credential has expired
};
Account getValidatedAccount();
Status getStatus();
}
Then used as:
Credentials creds = new UsernamePasswordCredentials("john", new
Password("welcome1"));
CredentialsValidationResult result =
identityManager.validateCredentials(creds);
if (Status.VALID.equals(*result*.getStatus())) {
// authentication was successful
}
Kind regards,
*
> Arjan Tijms
>
>
>
>
>
>
>
>
>
> On Fri, Jun 12, 2015 at 1:20 PM, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Hi,
>
> Great to see the proposal ;)
>
> I've got a few comments though that might be easier for now to put
> here.
>
> 1.
>
> I wonder if we shouldn't make a distinction first between a
> simpler "primary case" and the more advanced features as mentioned
> in the proposal.
>
> The primary case would focus on an identity store that's just
> "credentials in, username/groups out". This is the lowest common
> denominator of functionality that every other container out there
> implements. In CRUD terms this would basically translate to a READ
> of type getUsernameAndGroupsByCredential.
>
[Alex] This could definitely be built on top of the Identity Store
proposed. We could standardize a helper class... called Basic? ....
which would have convenience methods as you described.
>
> This is essentially what issue 18 asks
> (https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-18). Existing
> examples are the simple identity stores that are provided by e.g.
> Resin, Tomcat, JBoss, etc:
>
> *
> http://caucho.com/resin-4.0/admin/security-overview.xtp#Authenticators
> *
> https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#Standard_Realm_Implementations
> *
> http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Login_Modules.html#sect-UsersRolesLoginModule
>
> I was planning on doing a comparison article about which identity
> stores each server provides now, how their features compare, and
> what their interfaces in code look like. Unfortunately I haven't
> found the time to write this yet, but I'll look at the soon. Might
> be handy here ;)
>
> As for the other CRUD elements, these could be moved into a
> secondary case. This is in recognition that some applications may
> wish to fully store their users into the JSR 375 provided identity
> store, but other applications really only want to be able to pass
> the username and roles to the container from an authentication
> module and manage users via their own services.
>
[Alex] Regarding: "but other applications really only want to be able to
pass the username and roles to the container from an authentication
module and manage users via their own services. "
Would you please explain this use case? I guess the proposed Identity
Store would not be used in this case?
> It may additionally be that existing security datastores only
> allow a READ of type getUsernameAndGroupsByCredential.
>
[Alex] We could accommodate read only data stores in an implementation
of an IdentityStore interface
>
>
> 2.
>
> The role mapper is part of the proposal for the identity store.
> It's perhaps not 100% clear what's being mapped here. Is this the
> group to role mapper?
>
[Alex] The Grant class (i.e., role mapping, could be renamed) provides
the ability to programmatically assign and persist roles mapped to
Callers and Groups. If an application were to create/manage users stored
in the proposed Identity Store, that application would want to assign
roles to those users. That would be the purpose of the Grant.
How would the container learn about the Identity Store role mappings to
apply them to @ RolesAllowed, etc. ? I think we would need to define
that callback mechanism, unless we can think of a way to leverage
existing EE frameworks. I think the JASPIC GroupPrincipalCallback is for
groups not roles. We would also need to define rules regarding applying
Identity Store role mappings vs current container (glassfish-web.xml)
mappings for the application. Maybe the role mappings are additive?
Perhaps, the Identity Store role mappings should be limited to the
application scope.
> I think a group to role mapper in the traditional sense and as
> used currently by containers is almost always a separate entity,
> isn't it?. As a separate entity the group to role mapper can be
> used to map say a global LDAP group "senior_staff" to a local
> application role "admin". Default implementations can represent
> the existing group to role mappers that many containers use, e.g.
> in GlassFish the one that manages the mappings from glassfish-web.xml
>
[Alex] If that global LDAP group "senior_staff" were available via an
LDAP-based IdentityStore in the proposal, the mapping could also be done
as a Grant. We would need to define a mechanism for the container to
learn about that mapping.
>
>
> 3.
>
> A bit like as with 1. I wonder whether PartitionManager,
> RelationshipManager and IdentityManager are needed for the core
> store where we just standardize an interface for the existing
> identity stores that all containers are currently using.
>
> Not saying this all isn't nice or good to have, but just wondering
> if we shouldn't be taking smaller steps first. Especially "10.
> Identity Model Based on Attributes" introduces a lot of new types
> and concepts, where quite a number of them seem to go beyond the
> simple identity store and more or less represent quite a number of
> other stories.
>
[Alex] As with 1, I agree and propose we add a Basic helper class layer
to simply the usage. This would still expose the "advanced" layer in
case applications wanted more flexibility.
>
>
> 4.
>
> In 11.2, "Credential Validation", it's mentioned that
> IdentityManager.validateCredentials *would first ask the
> configuration for an IdentityStore* and specifically
> *Config.getStore would access the configuration to find a
> registered IdentityStore which supports the given credential type.*
>
> Now of course this is a high-level depiction of the flow, but it
> does sound like there's a custom registration and lookup mechanism
> involved here. In JSF we historically have had many of such
> mechansms as well, but we're now replacing them by CDI and for new
> functionality are using CDI directly.
>
> In this case, "access the configuration to find a registered
> IdentityStore which supports the given credential type", couldn't
> that just be a BeanManager/CDI.current call with IdentityStore as
> the class, and the given credential type as the qualifier?
>
> E.g.
>
> IdentityStore store = CDI.current().select(IdentityStore.class,
> usernamePasswordAnnotationLiteral);
>
> if (store.validateCredentials(credentials) == VALID) {
> // Authentication was successfull
> }
>
> Note that this is essentially issue 20
> (https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-20).
>
[Alex]
The IdentityStore and CredentialHandler instances would be looked up
based on XML and/or programmatic configuration. IdentityStore types
would be mapped to specific CredentialHandler types, since any
IdentityStore would not necessarily be able to store every credential
type. CredentialHandler type would be mapped to specific Credentials
type it supported. Given a Credential type, the look up would find a
supported IdentityStore (maybe the only one configured) and a supported
CredentialHandler for the Credential type.
The mappings may change per deployment, and the associated XML config
file would be configured appropriately. For example, different
IdentityStores could be configured for dev, test, stage, on-premise, and
cloud environments.
The proposal already specifies CDI support:
@Inject
IdentityManager identityManager;
Credentials creds = new UsernamePasswordCredentials("john", new
Password("welcome1"));
identityManager.validateCredentials(creds);
if (Status.VALID.equals(creds.getStatus())) {
// authentication was successful
}
>
> 5.
>
> One thing that is not explicitly mentioned is that identity stores
> should be provided by either the co ntainer, or by the
> application. In case they are provided by the container, the
> application often (but not always) needs to configure them.
>
[Alex] Are you talking about the backing store? The actual LDAP server
or database server? The proposed IdentityStore would have configurable
queries, update statements, etc and client connection parameters. The
LDAP or database server itself would be external to the proposed
Identity Store. I ran out of time at the end to specify this, as I
mentioned in my original email.
>
>
> This is a separate story, but it's essentially issue 9
> (https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-9).
>
> Hope this helps.
>
[Alex] Absolutely, thank you!
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jun 12, 2015 at 5:19 AM, Alex Kosowski
> <alex.kosowski_at_oracle.com <mailto:alex.kosowski_at_oracle.com>> wrote:
>
> Hi Experts,
>
> I have been working on an Identity Store proposal for which I
> would like your comments. Basically, I am proposing we model
> the Identity Store after PicketLink IdM.
>
> The proposal is published as a Google doc here:
> https://drive.google.com/open?id=1D9awD7DjMTctRWXrNKUgSw_tEDlHISr69-U8L8rGyBo&authuser=0
> <https://drive.google.com/open?id=1D9awD7DjMTctRWXrNKUgSw_tEDlHISr69-U8L8rGyBo&authuser=0>
>
> The proposal prototype is available here:
> https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/identity-store
>
> The proposal Google doc should be open for comments by anyone
> on the jsr375-experts_at_googlegroups.com
> <mailto:jsr375-experts_at_googlegroups.com> Google group. If you
> are having trouble commenting, please let me know. To comment,
> click the Comments button on the top right of the document.
>
> Note that I ran out of time, and Section 12 Attribute
> Management (and further) are currently marked "To Be
> Determined". I will get back to that.
>
> Regarding JSR 351 Identity API, I propose that JSR 351 would
> be integrated later (when available) as an IdentityStore
> implementation via the SPI. IdentityStore SPI could also be
> the integration point for server-specific identity stores. See
> the proposal to see what I mean by IdentityStore SPI.
>
> Please read the proposal and comment in the document.
>
> Thanks,
> Alex
>
>
>