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()?
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.
>
> 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. It may additionally be that existing security datastores only
> allow a READ of type getUsernameAndGroupsByCredential.
>
>
> 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?
>
> 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
>
>
> 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.
>
>
> 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).
>
>
> 5.
>
> One thing that is not explicitly mentioned is that identity stores should
> be provided by either the container, or by the application. In case they
> are provided by the container, the application often (but not always) needs
> to configure them.
>
> This is a separate story, but it's essentially issue 9 (
> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-9).
>
> Hope this helps.
>
> 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
>>
>> <https://docs.google.com/document/d/1D9awD7DjMTctRWXrNKUgSw_tEDlHISr69-U8L8rGyBo/edit?usp=sharing>
>> 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
>>
>>
>