On 5/22/15 8:31 PM, Alex Kosowski wrote:
> 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:
Hi Alex,
it was good to have a chance to talk with you last week, and thanks for
writing up a summary.
I should probably clarify, that I did not think that all of the
following should be done by JSR 375.
IMV jsr 375 should place a priority on standardizing a simple, portable
SAM configuration methodology
that is suitable for the Servlet profile.
> - 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.
>
Yes JSR 375 should not depend on JSR 351 being available for EE 8. That
is the main issue.
On the details, what I attempted to convey was that imv JSR 375 is
looking for a place for applications
to store, or package authentication information for "their users",
i.e., usernames, passwords, and
role memberships. It is also looking for interfaces that applications
can use to manage this info.
while JSR 351 has suitable lookup and update interfaces the mismatch is
more one of intended purpose.
JSR 351 is concerned with privacy, and would both discouraged the use of
identity repositories for storing
passwords, and would enforce an owner-centric access control model for
user attributes stored
in an identity repository. I suggested that what I saw being discussed
in JSR 375, seemed more like a
standardization of the concept of realm, as seen in the various forms in
the various EE containers,
and that could probably best be resolved by defining a common syntax or
schema for, i.e., something
akin to LDAP (and then building your interface on top of something like
JNDI or JDBC).
Ron
> 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>
>>>> .
>>>>
>>>>
>>>>
>>>
>>>