Hi Experts,
Ron Monzillo (spec lead for JASPIC and Identity API) and I met last week
and discussed JSR 375, JASPIC, and Identity API.
Regarding JASPIC JSR 196 [
https://jaspic-spec.java.net/]:
One of the goals of JSR 375 was to simplify application-defined
authentication, and enable applications to use custom authentication
mechanisms. JASPIC was identified by the JSR 375 EG as a currently
available framework to achieve that goal, but JASPIC was considered a
bit low-level and difficult for application developers to configure and
extend. Ron was concerned that JSR 375 was going to change the behavior
of JASPIC, but I mentioned we were considering changes like
https://java.net/jira/browse/JASPIC_SPEC-24 which would just add helpers
to make JASPIC easier for application developers to use.
Ron agreed that changes like these made sense for JSR 375 to specify:
- Standardize a utility class to register and configure a SAM for a
profile (e.g., servlet)
- Define annotations and DD to configure a SAM for a profile (e.g., servlet)
- Define a SAM helper class (inherited or delegated) to simplify SAM
implementation for specific profiles (e.g. servlet)
- Define/standardize an interface to represent SAM initialization
properties, to enable configuration
Regarding Identity API JSR 351
[
https://java.net/projects/identity-api-spec]:
Ron said we should not depend on JSR 351 being available in the EE 8
timeframe.
Although the attribute-oriented nature of JSR 351 may be useful for
specifying an attributed layer for a JSR 375 application-specified
identity store, Ron mentioned JSR 351 is generally not designed for such
a purpose. JSR 351 is meant for the aggregation of multiple ID providers
external to the application, providing secure, generally immutable
identities. The Identity Store we have been discussing in JSR 375 would
enable applications to manage their own identities. Although JSR 375
could use JSR 351 to implement an Identity Store, we would not be using
JSR 351 as designed.
However, there are parts of JSR 351 which we may find useful, for
example the entity-attribute model. And Ron mentioned that if we wanted
to use a subset of the JSR 351 API, he "may" be able to release a subset
of the API by EE 8.
I have been working on a proposal for an Identity Store to present to
the EG. At it's core is a PicketLink-like identity attribute model, for
which JSR 351 may be leveraged (or not). I will present that proposal
shortly.
Kind regards,
Alex
On 5/14/15 12:14 AM, Alex Kosowski wrote:
> Hi Werner,
>
> Coincidentally, I am currently visiting the Boston area, meeting with
> Ron tomorrow to discuss synergies between JSR 375, JSR 351, and
> JASPIC. I will report back.
>
> Regards,
> Alex
>
> On 5/13/15 10:32 AM, Werner Keil wrote:
>> Ron/all
>>
>> You may have heard, that except for JSR 350 (State Management which
>> also failed to produce an EDR or similar notable output) all renewal
>> or other ballots passed this week. Including 351. Some notable
>> concers raised were available resources and time of the Spec Leads.
>> Even a few who voted "Yes" or abstained mentioned a possible "Open
>> Source PoC" could be better.
>>
>> Looking at possible synergies for JSR 375 especially some sort of
>> "attribute sub-system" among other areas that 351 may provide to 375
>> or other Security frameworks, would it be possible to communicate
>> between both JSRs and Spec Leads, especially since all of you work
>> for Oracle after all, it should make it even a bit easier.
>>
>> Being fairly Maven enabled and on Git already, I guess Nobis could
>> also be of use to some of the JSR 375 Security Proposals and vice versa.
>> I noticed, the Nobis wiki https://java.net/projects/nobis/pages/Home
>> still said it's licensed under Apache 2.0, but POMs pretty much all
>> look like Glassfish ones, so that must be some legacy intent (before
>> e.g. Jim and Oracle Legal started to oppose Apache, especially for
>> platform relevant JSRs;-)
>>
>> Regards,
>>
>> Werner
>>
>>
>> On Thu, May 7, 2015 at 1:20 PM, Ron Monzillo <ron.monzillo_at_oracle.com
>> <mailto:ron.monzillo_at_oracle.com>> wrote:
>>
>>
>>
>> On 5/7/15 6:15 AM, Werner Keil wrote:
>>> Ron/all,
>>>
>>> Looking at existing elements of JSR 351 you also highlighted like
>>> 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#getAttributeLookupService%28%29>
>>> https://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeProvider.html#getAttributeUpdateService()
>>> <https://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeProvider.html#getAttributeUpdateService%28%29>
>>>
>>> it is safe to assess, a key focus of JSR 351 in EDR stage was
>>> "Attribute-Based Access Control" (ABAC)
>>>
>>> Beside commercial vendors, e.g. below, standard bodies like NIST
>>> have dealt with the matter for some time:
>>> http://en.wikipedia.org/wiki/Attribute-based_access_control
>>>
>>> I guess there are certainly things in 351 beneficial to the
>>> cause if the Renewal Ballot passed and 351 was allowed to continue.
>>>
>>> Regards,
>>>
>>> Werner
>>>
>>
>> Thanks Werner, and you are correct that providing attributes for ABAC
>> has been an important driver for the API.
>>
>> Hopefully the renewal ballot will pass, and thanks for your support.
>>
>> Ron
>>
>>
>>>
>>> *Gesendet:* Donnerstag, 07. Mai 2015 um 11:50 Uhr
>>> *Von:* Axiomatics <marketing_at_axiomatics.com
>>> <mailto:marketing_at_axiomatics.com>>
>>> *An:* "Werner Keil" <werner_at_catmedia.us <mailto:werner_at_catmedia.us>>
>>> *Betreff:* [Infographic]: Why you should shift to
>>> Attribute-based Access Control
>>>
>>> Click here
>>> <http://ma.axiomatics.com/acton/ct/10529/s-00dc-1505/Bct/q-5f6c/l-0013:6647/ct0_0/1?sid=KYkVip9hj> to
>>> view this message in a browser window
>>>
>>>
>>>
>>> <http://ma.axiomatics.com/acton/ct/10529/s-00dc-1505/Bct/q-5f6c/l-0013:6647/ct1_0/1?sid=KYkVip9hj>
>>>
>>>
>>>
>>> <http://ma.axiomatics.com/acton/ct/10529/s-00dc-1505/Bct/q-5f6c/l-0013:6647/ct2_0/1?sid=KYkVip9hj>
>>> <http://ma.axiomatics.com/acton/ct/10529/s-00dc-1505/Bct/q-5f6c/l-0013:6647/ct3_0/1?sid=KYkVip9hj> <http://ma.axiomatics.com/acton/ct/10529/s-00dc-1505/Bct/q-5f6c/l-0013:6647/ct4_0/1?sid=KYkVip9hj>
>>>
>>>
>>> What can Attribute-based Access Control do for you?
>>>
>>>
>>> Check out this infographic to ease the pain.
>>>
>>> From the board room to the database administrator - we're all
>>> being kept up by the threat of sensitive data getting into the
>>> wrong hands. We've all got different reasons for this -
>>> sometimes it's compliance, sometimes it's fraud. Whatever the
>>> driver- enterprises and government agencies alike know that data
>>> access control is paramount to a business' data security goals.
>>> Now, many of these organizations are making the shift to
>>> externalized authorization and fine-grained access control.
>>>
>>>
>>> You've probably heard about ABAC - but maybe you're
>>> overwhelmed by it. Read on to find out how making the
>>> shift to this approach can help you meet your IT security
>>> goals.
>>>
>>>
>>> The ABAC Factor Infographic
>>> <http://ma.axiomatics.com/acton/ct/10529/s-00dc-1505/Bct/q-5f6c/l-0013:6647/ct5_0/1?sid=KYkVip9hj>
>>>
>>>
>>> The ABAC Factor Infographic
>>> <http://ma.axiomatics.com/acton/ct/10529/s-00dc-1505/Bct/q-5f6c/l-0013:6647/ct5_1/1?sid=KYkVip9hj>
>>>
>>>
>>>
>>>
>>>
>>> Click here to opt out
>>> <http://ma.axiomatics.com/acton/rif/10529/s-00dc-1505/-/l-0013:6647/q-5f6c/zout?sid=KYkVip9hj>
>>>
>>> For more information about Axiomatics visit our website
>>> www.axiomatics.com
>>> <http://ma.axiomatics.com/acton/ct/10529/s-00dc-1505/Bct/q-5f6c/l-0013:6647/ct1_1/1?sid=KYkVip9hj>
>>> or send an email to info_at_axiomatics.com
>>> <https://3c.gmx.net/mail/client/mail/compose/info@axiomatics.com> .
>>>
>>>
>>>
>>
>>