On 4/10/15 2:51 PM, Werner Keil wrote:
> Pedro/all,
>
> Good point, thanks for highlighting that. Assuming both JSRs progress
> and remain active, 351 could act as a detailed API or SPI for identity
> attributes. With 375 on top.
> Such synergies could also help CDI integration which 351 aims for
> (based on CDI 1) but I don't recall we got there yet.
>
> Werner
>
> On Fri, Apr 10, 2015 at 8:15 PM, Pedro Igor Silva <psilva_at_redhat.com
> <mailto:psilva_at_redhat.com>> wrote:
>
> I took a look at JSR-351 draft and I noticed that there is no
> reference to an Identity Store API, as we are considering it in
> this spec.
>
Hi Pedro,
The JSR 351 API (Early Draft) is available here:
https://identity-api-spec.java.net/nonav/1.0/apidocs/index.html
Note that the early draft defined both lookup and update interfaces;
which are available from an AttributeProvider (impl).
Not all such implementations must offer both interfaces.
https://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeProvider.html#getAttributeLookupService()
https://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeProvider.html#getAttributeUpdateService()
Sorry if I misunderstood what you meant by an "Identity Store API".
Ron
BTW, Attribute Providers are acquired from the ProviderLookupService;
which is basically the client facing view of the JSR 351 Attribute Service
https://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/client/ProviderLookupService.html
its provides some access control on access to attribute providers, and
provides some entity composition (unions, and joins) functionality
>
> However, if I understood it correctly, JSR-351 gives a different
> look on how we represent identities, with more focus on attributes
> and how you store and use them to actually represent identities.
> You see a lot of references about an Attribute Service though,
> which seems to be a core concept on that spec.
>
> I really like the attribute-oriented design of that spec. I think
> it is pretty related with what I said in a different thread about
> ABAC and how an attribute-based approach can help to provide a
> more flexible authentication and authorization model. Within an
> identity, everything can be represented as an attribute or claim,
> even roles, groups or whatever you want.
>
> IMO, an Identity Store interface where you have methods to CRUD
> identities (eg.: user) is not enough. Attributes alone can be used
> in different use cases such as those described by that spec. And
> also when dealing with identity federation use cases.
>
> Any thoughts ?
>
> ----- Original Message -----
> From: "Alex Kosowski" <alex.kosowski_at_oracle.com
> <mailto:alex.kosowski_at_oracle.com>>
> To: "Ron Monzillo" <ron.monzillo_at_oracle.com
> <mailto:ron.monzillo_at_oracle.com>>
> Cc: jsr375-experts_at_javaee-security-spec.java.net
> <mailto:jsr375-experts_at_javaee-security-spec.java.net>, "PRATEEK
> MISHRA" <PRATEEK.MISHRA_at_oracle.com <mailto:PRATEEK.MISHRA_at_oracle.com>>
> Sent: Friday, April 10, 2015 2:03:36 PM
> Subject: [jsr375-experts] Re: JSR 351 Identity API Status?
>
> Thanks for your response, Ron!
>
> At present, EE 8 is scheduled for completion Q3 2016.
>
> The JSR 375 EG had mentioned that there was some overlap between
> JSR 375
> and JSR 351 wrt Identity Store API. My original intent was that
> JSR 375
> would provide an app dev friendly simplified view of an Identity
> Store,
> with the option to access the full JSR 351 API, if that backed the
> simplified view. What is "simplified" is up for discussion.
>
> It will, of course, be difficult to depend on JSR 351, if it is not
> available ;)
>
> At the very least, I do not think we want to specify anything that
> conflicts with JSR 351.
>
> Although the JSR 351 API is quite comprehensive, I wonder if a
> "non-security expert" application developer coming from Apache
> Shiro or
> Spring Security, would understand it. I wonder if there is some
> opportunity for JSR 375 to simplify JSR 351.
>
> Since JSR 351 would not be available by EE 8, I wonder if we
> should try
> a more direct approach and define Identity Store access backed by
> commonly used persistence mechanisms like file, DB, and LDAP.
>
> Regards,
> Alex
>
> On 4/10/15 5:14 PM, Ron Monzillo wrote:
> > On 4/9/15 7:37 PM, Alex Kosowski wrote:
> >> Hi Prateek and Ron,
> >>
> >> Do you suspect JSR 351 will be completed in the EE 8 timeframe?
> >>
> >> Thanks,
> >> Alex
> > Hi Alex,
> >
> > I don't think I can commit to JSR 351 being completed in time
> for EE 8.
> >
> > I have committed to produce a revision to the early draft.. The
> > revision will
> > focus on filling in the security aspects of the api, simplifying
> > attribute repository
> > configuration/registration, and on simplifying repository
> development and
> > integration by allowing for repositories that implement a subset of
> > the specified
> > query and update capabilities.
> >
> > BTW, what is the EE8 timeframe?
> >
> > Ron
>
>