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
>
>