Please do, and you're right, the full JavaDoc (or sources in Git I pointed
to before) unveils, there's a javax.security.identity.auth package, too.
So whether or not JSR 375 uses some of its package spaces to explore
synergies or not, especially mayhem like
javax.security.auth
vs.
javax.security.identity.auth
is something we should avoid at all costs.
A bit like what Mike Keith and a few in the JCP EC (including myself)
helped JSRs 330 and 299 (CDI 1.0) to coordinate and avoid reinventing the
wheel on either side;-)
Cheers,
Werner
On Thu, Apr 9, 2015 at 6:36 PM, Darran Lofthouse <
darran.lofthouse_at_redhat.com> wrote:
> Will have a thorough read of that one this evening but from a cursory
> glance there does appear IMO to be quite an overlap with JSR-375.
>
> Regards,
> Darran Lofthouse.
>
>
> On 09/04/15 17:26, Werner Keil wrote:
>
>> For starters please check the detail page including EDR download:
>> https://jcp.org/en/jsr/detail?id=351
>> I am also in the 351 EG but regular calls that took place till some time
>> in 2013 did not happen after the EDR (at least I was not aware of)
>>
>> Regards,
>> Werner
>>
>> On Thu, Apr 9, 2015 at 6:16 PM, Darran Lofthouse
>> <darran.lofthouse_at_redhat.com <mailto:darran.lofthouse_at_redhat.com>> wrote:
>>
>> +1 it would be good to know where that JSR is currently at. IMO the
>> general scope trying to be covered by this JSR has a large overlap
>> with identity in general and rather than having two different
>> representations within EE maybe this is an opportunity to build on
>> what they have so far within that JSR.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 09/04/15 16:59, Werner Keil wrote:
>>
>> P.s.:
>> Since JSR 351 (Identity JSR) did publish an Early Draft a little
>> over a
>> year ago, unless it has since been "put to sleep" inside Oracle,
>> please
>> also have a look at its API terms and definitions:
>> https://java.net/projects/__identity-api-spec/sources/git/
>> __show/IdentityApiGit/src/main/__java/javax/security/identity
>> <https://java.net/projects/identity-api-spec/sources/git/
>> show/IdentityApiGit/src/main/java/javax/security/identity>
>> Given if both JSRs went final side-by-side or together they share
>> a
>> common "javax.security" namespace after all.
>>
>> The closest could be AttributeProvider/__AttributeRepository,
>> though 351
>> applies this a bit more high level and generic I'd say.
>> Have a word with Ron and Prateek if you can. At least the term
>> "IdentityStore" may overlap with 351 though it has not used that
>> particular name anywhere at the moment.
>>
>> Werner
>>
>> On Thu, Apr 9, 2015 at 5:38 PM, arjan tijms
>> <arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>
>> <mailto:arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>>__>
>> wrote:
>>
>> Hi,
>>
>> On Thu, Apr 9, 2015 at 5:18 PM, Werner Keil
>> <werner.keil_at_gmail.com <mailto:werner.keil_at_gmail.com>
>> <mailto:werner.keil_at_gmail.com
>>
>> <mailto:werner.keil_at_gmail.com>>__> wrote:
>> > Actually "IdentityStore" is also used in different
>> PicketLink modules.
>> > So it uses "PermissionStore" in the context of
>> "Authorization"/ACL and
>> > "IdentityStore" on the Authentication side.
>>
>> There are a few other terms indeed. The list I presented
>> earlier is
>> already long, and still there are more terms. IBM for
>> instance calls
>> it "user registry" (have to double check whether it's
>> really the same,
>> but I think it is).
>>
>>
>> > If we purely deal with Authentication, either
>> "IdentityStore" or
>> > "AuthenticationStore" sound best.
>> > Otherwise I'd say "PermissionStore" (or "SecurityStore"
>> to have another
>> > prefix to the simple "Store") sound more versatile.
>>
>> Do note that for now it's not about picking the absolute
>> best or final
>> term, but just to establish at least a working term.
>>
>> Any way, I think I can list 6 voters now:
>>
>> David Blevins: Store
>> Arjan Tijms: Authentication Store
>> Alex Kosowski: Authentication Store / Identity Store
>> Rudy De Busscher: Security Provider
>> Darran Lofthouse: Realm / Identity Store
>> Werner Keil: Authentication Store / Identity Store
>>
>>
>> Organized per term:
>>
>> Authentication Store - 3
>> Identity Store - 3
>> Store - 1
>> Security Provider - 1
>> Realm - 1
>>
>> @David, you said just "store" before, but from your comment
>> it looked
>> like you would have been okay with a variation. Would you
>> like to
>> change it to either "Authentication Store" or "Identity
>> Store", or is
>> just "store" really your preferred term?
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>>
>> >
>> > Werner
>> >
>> > On Thu, Apr 9, 2015 at 5:08 PM, Werner Keil
>> <werner.keil_at_gmail.com <mailto:werner.keil_at_gmail.com>
>> <mailto:werner.keil_at_gmail.com <mailto:werner.keil_at_gmail.com>>__>
>> wrote:
>> >>
>> >> PicketLink calls it PermissionStore. I could think of
>> variations
>> including
>> >> SecurityStore (just Store seems a bit too wide)
>> >> but PermissionStore sounds fine to me.
>> >>
>> >> Regards,
>> >> Werner
>> >>
>> >> On Thu, Apr 9, 2015 at 4:32 PM, Darran Lofthouse
>> >> <darran.lofthouse_at_redhat.com
>> <mailto:darran.lofthouse_at_redhat.com>
>> <mailto:darran.lofthouse@__redhat.com
>>
>> <mailto:darran.lofthouse_at_redhat.com>>> wrote:
>> >>>
>> >>> Looks like I replied but did not vote ;-)
>> >>>
>> >>> My vote would be Realm or Identity Store.
>> >>>
>> >>> Whilst I agree it's first use will be authentication I
>> think it
>> has the
>> >>> potential to be widely referenced after authentication.
>> >>>
>> >>> Regards,
>> >>> Darran Lofthouse.
>> >>>
>> >>>
>> >>>
>> >>> On 09/04/15 15:24, arjan tijms wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> We now have 4 votes:
>> >>>>
>> >>>> David Blevins: Store
>> >>>> Arjan Tijms: Authentication Store
>> >>>> Alex Kosowski: Authentication Store / Identity Store
>> >>>> Rudy De Busscher: Security Provider
>> >>>>
>> >>>> No other people have voted yet, although there have
>> been some
>> >>>> additional comments.
>> >>>>
>> >>>> Based on this, shall we establish "authentication
>> store" as the
>> >>>> working term? Just so we all know what we're talking
>> about.
>> The final
>> >>>> term can be something else still.
>> >>>>
>> >>>> Kind regards,
>> >>>> Arjan
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Mon, Mar 23, 2015 at 11:13 PM, arjan tijms
>> <arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>
>> <mailto:arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>>__>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> On Mon, Mar 23, 2015 at 10:32 PM, Alex Kosowski
>> >>>>> <alex.kosowski_at_oracle.com
>> <mailto:alex.kosowski_at_oracle.com>
>> <mailto:alex.kosowski_at_oracle.__com
>>
>> <mailto:alex.kosowski_at_oracle.com>>>
>>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> To add a 13th option,
>> >>>>>>
>> >>>>>> How about IdentityStore? That would reflect that we
>> are storing
>> >>>>>> identity
>> >>>>>> attributes.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> I could absolutely see that working as well, sure. In
>> terminology it
>> >>>>> has
>> >>>>> some connection with a JSR that was started some
>> time ago,
>> the Java
>> >>>>> Identity
>> >>>>> API (JSR 351), and with the term "authenticated
>> identity"
>> (the more
>> >>>>> formal
>> >>>>> alternative for "logged-in user").
>> >>>>>
>> >>>>> But is Identity Store also a preference you have for
>> the
>> term, or just
>> >>>>> an
>> >>>>> alternative idea?
>> >>>>>
>> >>>>> Giving the overview again, it would now be:
>> >>>>>
>> >>>>> David Blevins: Store
>> >>>>> Arjan Tijms: Authentication Store
>> >>>>> Alex Kosowski: Authentication Store / Identity Store
>> >>>>> Rudy De Busscher: Security Provider
>> >>>>>
>> >>>>> Kind regards,
>> >>>>> Arjan Tijms
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 3/23/15 5:15 PM, Rudy De Busscher wrote:
>> >>>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>>> the concept of "the store where users/callers and
>> optionally the
>> >>>>>>> group/role data resides".
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Since you also have the group/role information, it
>> is not only
>> >>>>>> Authentication info anymore. So Authentication
>> Store is then
>> >>>>>> confusing.
>> >>>>>>
>> >>>>>> Store is indeed too general, so what about security
>> provider
>> (if I
>> >>>>>> have to
>> >>>>>> take a term from the list proposed here)?
>> >>>>>>
>> >>>>>> regards
>> >>>>>> Rudy
>> >>>>>>
>> >>>>>> On 23 March 2015 at 22:03, arjan tijms
>> <arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>
>> <mailto:arjan.tijms_at_gmail.com <mailto:arjan.tijms_at_gmail.com>>__>
>> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>> On Monday, March 23, 2015, Alex Kosowski
>> <alex.kosowski_at_oracle.com <mailto:alex.kosowski_at_oracle.com>
>> <mailto:alex.kosowski_at_oracle.__com
>>
>> <mailto:alex.kosowski_at_oracle.com>>>
>>
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Hi Arjan,
>> >>>>>>>>
>> >>>>>>>> Does this indicates your preference, or is it
>> just the
>> term Shiro
>> >>>>>>>> happened to use?
>> >>>>>>>>
>> >>>>>>>> It was just a starting point.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Okay ;)
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> David Blevins: Store
>> >>>>>>>> Arjan Tijms: Authentication Store
>> >>>>>>>>
>> >>>>>>>> Authentication Store is fine with me. Store seems
>> a little
>> broad,
>> >>>>>>>> but
>> >>>>>>>> less typing.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Yes, for me too just store would feel too broad.
>> AuthStore
>> would seem
>> >>>>>>> to
>> >>>>>>> work at first, but I agree with Les who stated in
>> another
>> thread that
>> >>>>>>> we
>> >>>>>>> shouldn't use just "auth" anywhere.
>> >>>>>>>
>> >>>>>>> While very common, it unfortunately makes it hard to
>> distinguish
>> >>>>>>> between
>> >>>>>>> authentication and authorization.
>> >>>>>>>
>> >>>>>>> So we now have;
>> >>>>>>>
>> >>>>>>> David Blevins: Store
>> >>>>>>> Arjan Tijms: Authentication Store
>> >>>>>>> Alex Kosowski; Authentication Store
>> >>>>>>>
>> >>>>>>> Anyone else?
>> >>>>>>>
>> >>>>>>> Kind regards,
>> >>>>>>> Arjan Tijms
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Thanks,
>> >>>>>>>> Alex
>> >>>>>>>>
>> >>>>>>>> On 3/20/15 8:56 AM, arjan tijms wrote:
>> >>>>>>>>
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>> The doc is a great start, thanks Alex :)
>> >>>>>>>>
>> >>>>>>>> I noticed that relevant to the issue described in
>> this
>> thread, the
>> >>>>>>>> document has chosen the term "Realm" for the
>> concept of
>> "the store
>> >>>>>>>> where
>> >>>>>>>> users/callers and optionally the group/role data
>> resides".
>> >>>>>>>>
>> >>>>>>>> Does this indicates your preference, or is it
>> just the
>> term Shiro
>> >>>>>>>> happened to use?
>> >>>>>>>>
>> >>>>>>>> What about a round of voting (non-binding at this
>> stage,
>> just to
>> >>>>>>>> test
>> >>>>>>>> the waters)? That way we at least can establish a
>> working
>> term that
>> >>>>>>>> we can
>> >>>>>>>> use in the different discussions and issues that
>> have
>> already all
>> >>>>>>>> started to
>> >>>>>>>> use different terms.
>> >>>>>>>>
>> >>>>>>>> The list of proposed terms is now the following:
>> >>>>>>>>
>> >>>>>>>> security provider (WebLogic)
>> >>>>>>>> realm (Tomcat, Shiro, some hints in Servlet spec)
>> >>>>>>>> (authentication) repository
>> >>>>>>>> (authentication) store
>> >>>>>>>> login module (JAAS)
>> >>>>>>>> identity manager (Undertow)
>> >>>>>>>> service provider
>> >>>>>>>> relying party
>> >>>>>>>> authenticator (Resin, OmniSecurity, Seam Security)
>> >>>>>>>> user service (?, used by 375 JSR)
>> >>>>>>>> authentication provider (Spring Security)
>> >>>>>>>> identity provider
>> >>>>>>>>
>> >>>>>>>> I'd like to ask everyone on this list to vote for
>> your
>> preferred
>> >>>>>>>> term.
>> >>>>>>>> David had already expressed favoring "store" in
>> the JIRA
>> issue,
>> >>>>>>>> which is
>> >>>>>>>> together with "repository" also my favorite,
>> although I
>> like to
>> >>>>>>>> prefix it
>> >>>>>>>> with "authentication".
>> >>>>>>>>
>> >>>>>>>> So the current outcome is:
>> >>>>>>>>
>> >>>>>>>> David Blevins: Store
>> >>>>>>>> Arjan Tijms: Authentication Store
>> >>>>>>>>
>> >>>>>>>> Kind regards,
>> >>>>>>>> Arjan Tijms
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Thu, Mar 19, 2015 at 3:25 AM, Alex Kosowski
>> >>>>>>>> <alex.kosowski_at_oracle.com
>> <mailto:alex.kosowski_at_oracle.com>
>> <mailto:alex.kosowski_at_oracle.__com
>> <mailto:alex.kosowski_at_oracle.com>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Hi,
>> >>>>>>>>>
>> >>>>>>>>> I created a draft document for adding/editing EE
>> Security API
>> >>>>>>>>> Terminology on an on-going basis.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> https://docs.google.com/__document/d/__
>> 1eaNCUa78Eytt73WYvDHrsS3klTzHL__0xD5vswHhT-KVY/edit?usp=__sharing
>> <https://docs.google.com/document/d/
>> 1eaNCUa78Eytt73WYvDHrsS3klTzHL0xD5vswHhT-KVY/edit?usp=sharing>
>> >>>>>>>>>
>> >>>>>>>>> This a Google doc viewable by the public and
>> editable by
>> those in
>> >>>>>>>>> the
>> >>>>>>>>> Google Group jsr375-experts_at_googlegroups.__com
>> <mailto:jsr375-experts_at_googlegroups.com>
>> <mailto:jsr375-experts@__googlegroups.com
>> <mailto:jsr375-experts_at_googlegroups.com>>, of which all of you
>>
>> >>>>>>>>> should be
>> >>>>>>>>> a member.
>> >>>>>>>>>
>> >>>>>>>>> Alex
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On 3/8/15 5:01 PM, arjan tijms wrote:
>> >>>>>>>>>
>> >>>>>>>>> Hi there,
>> >>>>>>>>>
>> >>>>>>>>> A while ago I created
>> >>>>>>>>>
>> https://java.net/jira/browse/__JAVAEE_SECURITY_SPEC-1
>> <https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-1>,
>>
>> which seeks to
>> >>>>>>>>> establish clear terminology for two concepts
>> that often
>> come up in
>> >>>>>>>>> authentication:
>> >>>>>>>>>
>> >>>>>>>>> 1. The (user) interaction method via which
>> credentials are
>> >>>>>>>>> obtained
>> >>>>>>>>> (FORM, BASIC, etc)
>> >>>>>>>>> 2. The store where users/callers and
>> optionally the
>> group/role
>> >>>>>>>>> data
>> >>>>>>>>> resides
>> >>>>>>>>>
>> >>>>>>>>> Not only do I see very different terms being
>> used for
>> both of these
>> >>>>>>>>> concepts which is a problem by itself, but the
>> lack of
>> consistent
>> >>>>>>>>> terminology makes it unclear what people are
>> really asking at
>> >>>>>>>>> times.
>> >>>>>>>>>
>> >>>>>>>>> Your thoughts?
>> >>>>>>>>>
>> >>>>>>>>> Kind regards,
>> >>>>>>>>> Arjan Tijms
>>
>>
>>