users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Re: 1-TerminologyAuthInteractionVsStore ACTION: cast vote

From: Rudy De Busscher <rdebusscher_at_gmail.com>
Date: Mon, 23 Mar 2015 22:15:39 +0100

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

> Hi,
>
> On Monday, March 23, 2015, Alex Kosowski <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:
>>
>> 1. security provider (WebLogic)
>> 2. realm (Tomcat, Shiro, some hints in Servlet spec)
>> 3. (authentication) repository
>> 4. (authentication) store
>> 5. login module (JAAS)
>> 6. identity manager (Undertow)
>> 7. service provider
>> 8. relying party
>> 9. authenticator (Resin, OmniSecurity, Seam Security)
>> 10. user service (?, used by 375 JSR)
>> 11. authentication provider (Spring Security)
>> 12. 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>
>> 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/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, of which all of you
>>> should be a member. <http://jsr375-experts@googlegroups.com,>
>>>
>>> Alex
>>>
>>>
>>> On 3/8/15 5:01 PM, arjan tijms wrote:
>>>
>>> Hi there,
>>>
>>> A while ago I createdhttps://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
>>>
>>>
>>
>
>
>
>
>
>