On 20/03/15 12:56, 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
Within the work we are undertaking for the Elytron project that is going
into WildFly the terminology that we are using at the moment is that a
Realm is a essentially a backing store of account information /
identities. We then have Domain which is an aggregation of realms.
One thing we consider however is that role information is potentially
separate from the store, i.e. the authenticated account is associated
with a realm - as they access a secured resource they are assigned roles
in the context of that resource. For simplicity this could be a 1:1
mapping with something associated with the user in that realm or it
could be a more complex mapping.
This does remind me it is probably worth minimising the use of terms
that suggest a human client and instead stick to more general terms such
as account or identity.
FYI Undertow is mentioned in the above list but that is currently under
review to switch to the domain / realm definition in my first paragraph.
> 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>> 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 created
>> 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
>
>
--
Darran Lofthouse - Principal Software Engineer
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson
(US), Michael O'Neill(Ireland)