Alex/all,
Thanks for the update. I also changed the slides Jean-Louis and I were
invited to present to the JCP EC on Monday replacing the topic with
"Identity Management" except in the pictures or JIRA epic. As the meeting
is for the EC and those presenting I only shared the Google Doc with Alex
and Jean-Louis to edit or comment but the PMO will make the PDF available
after the F2F to everyone on jcp.org.
Here's the read only view for now
https://docs.google.com/presentation/d/17ydb3RPTGKPgzWRQ7S9HKtDjL5aeJEWQodjrq0Ga6i0/edit?usp=sharing
Regards,
Werner
On Sat, Jun 13, 2015 at 3:10 AM, Alex Kosowski <alex.kosowski_at_oracle.com>
wrote:
> 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, 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>
> 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>
>> 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
>>>
>>> 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 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
>>>
>>>
>>
>