Just to provide a little more background on the name within Undertow,
within JBoss AS7 and WildFly we also heavily use SASL for non-HTTP based
authentication, within SASL this 'thing' is essentially referred to as a
'mechanism': -
https://docs.oracle.com/javase/8/docs/api/javax/security/sasl/SaslServerFactory.html
So when the API was visited within Undertow the name Authentication
Mechanism was selected.
Within the servlet spec I think it lost it's way slightly, as you point
out within the web.xml it is an auth-method, however on the
HttpServletRequest interface getMethod relates to the method of the
request e.g. GET, POST - the approach used for authentication then comes
from a getAuthType method.
At the moment my vote would be to stick with 'Authentication Mechanism'
but obviously this is more about the logic I already used once so open
to other input ;-)
Regards,
Darran Lofthouse.
On 16/04/15 14:23, arjan tijms wrote:
> Hi again,
>
> Now that we seem to have largely agreed on the working term "identity
> store", it's time to consider the next term mentioned in
> JAVAEE_SECURITY_SPEC-1, which is the term for the "the (user)
> interaction method via which credentials are obtained (form, basic,
> etc)".
>
> I didn't research this intensively, but after a quick look I
> discovered the following terms:
>
> * auth-method (Servlet, web.xml)
> * authentication mechanism (Undertow)
> * authenticator (Tomcat)
> * (server) auth module/SAM (JASPIC)
>
> Concrete code examples to make it hopefully extra clear what's meant here:
>
> Undertow: http://grepcode.com/file/repo1.maven.org/maven2/io.undertow/undertow-core/1.2.0.Beta8/io/undertow/security/impl/FormAuthenticationMechanism.java#FormAuthenticationMechanism
>
> Tomcat: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/8.0.20/org/apache/catalina/authenticator/FormAuthenticator.java#FormAuthenticator
>
> Both implement the well known Servlet FORM.
>
> In the case of Undertow we see:
>
> FormAuthenticationMechanism#authenticate
> - Extract username/password from request
> - Call out to "identity store": Account account =
> identityManager.verify(userName, credential);
> - Establish authenticated identity:
> securityContext.authenticationComplete(account, name, true);
>
> In the case of Tomcat we see:
>
> FormAuthenticator#authenticate
> - Extract username/password from request
> - Call out to "identity store": principal =
> realm.authenticate(username, password);
> - AuthenticatorBase#register(request, response, principal, ...);
>
> Do note the extra level of confusion regarding the term
> "authenticator". In Tomcat this is the interaction mechanism, while in
> Resin this is exactly the opposite thing, namely the "identity store"
> (which is called Realm in Tomcat).
>
> I'll start with voting for "authentication mechanism":
>
> Arjan Tijms - authentication mechanism
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> On Mon, Apr 13, 2015 at 7:46 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>> Hi,
>>
>> On Monday, April 13, 2015, Adam Bien <abien_at_adam-bien.com> wrote:
>>>
>>> I'm for Identity Store or Realm
>>
>>
>> I think that means we have a winner ;)
>>
>> Identity store - 8
>> Realm - 4
>>
>> If the 3 remaining people would all vote realm now then identity store would
>> still win.
>>
>>
>>>
>>> I think Java EE borrowed the term "Realm" from Basic Authentication:
>>> http://tools.ietf.org/html/rfc2617 ("Protection Space")
>>
>>
>> I think so too, and I always got the feeling that "realm" should only apply
>> to basic authentication in web.xml. But because of a lack of any other way
>> it's also often used for the FORM authentication mechanism to let the user
>> indicate which identity store to use for it.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>>
>>>
>>> A realm could be anything, but from pragmatic point of view it is an
>>> Identity Store.
>>>> On 13.04.2015, at 17:52, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Fri, Apr 10, 2015 at 10:23 AM, Ivar Grimstad
>>>> <ivar.grimstad_at_gmail.com> wrote:
>>>>> Identity Store for me.
>>>>
>>>> Thanks for the vote! Current status is now:
>>>>
>>>> 10 out of 14 voted:
>>>>
>>>> David Blevins: Store
>>>> Arjan Tijms: Authentication Store
>>>> Alex Kosowski: Identity Store
>>>> Rudy De Busscher: Security Provider
>>>> Darran Lofthouse: Realm / Identity Store
>>>> Werner Keil: Authentication Store / Identity Store
>>>> Ajay Reddy: Identity Store / User Repository / Realm
>>>> Pedro Igor: Identity Store
>>>> Jean-Louis Monteiro: Authentication Store / Store
>>>> Ivar Grimstad: Identity Store
>>>>
>>>>
>>>> Organized per term:
>>>>
>>>> Identity Store - 6
>>>> Authentication Store - 3
>>>> Realm - 3
>>>> Store - 1
>>>> Security Provider - 1
>>>> User Repository - 1
>>>>
>>>> I'm willing to change my vote to "Identity Store" as well, so we'd then
>>>> have:
>>>>
>>>> David Blevins: Store
>>>> Arjan Tijms: Identity Store
>>>> Alex Kosowski: Identity Store
>>>> Rudy De Busscher: Security Provider
>>>> Darran Lofthouse: Realm / Identity Store
>>>> Werner Keil: Authentication Store / Identity Store
>>>> Ajay Reddy: Identity Store / User Repository / Realm
>>>> Pedro Igor: Identity Store
>>>> Jean-Louis Monteiro: Authentication Store / Store
>>>> Ivar Grimstad: Identity Store
>>>>
>>>>
>>>> Organized per term:
>>>>
>>>> Identity Store - 7
>>>> Realm - 3
>>>> Authentication Store - 2
>>>> Store - 1
>>>> Security Provider - 1
>>>> User Repository - 1
>>>>
>>>> So if Adam Bien, Will Hopkins, Matt Konda and Les Hazlewood all voted
>>>> "realm" we'd have a tie, but otherwise there's not much that stands in
>>>> the way of "identity store" for the working term.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> On Apr 10, 2015 9:16 AM, "arjan tijms" <arjan.tijms_at_gmail.com> wrote:
>>>>>>
>>>>>> On Fri, Apr 10, 2015 at 8:44 AM, Jean-Louis Monteiro
>>>>>> <jlmonteiro_at_tomitribe.com> wrote:
>>>>>>> Oups, thought I voted but looks like no.
>>>>>>>
>>>>>>> If it's still time, "authentication store" for me if we wan't to
>>>>>>> really
>>>>>>> qualify what's the store is about.
>>>>>>> Otherwise "store" only is enough.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Latest votes overview then becomes:
>>>>>>
>>>>>> 9 out of 14 voted:
>>>>>>
>>>>>> David Blevins: Store
>>>>>> Arjan Tijms: Authentication Store
>>>>>> Alex Kosowski: Identity Store
>>>>>> Rudy De Busscher: Security Provider
>>>>>> Darran Lofthouse: Realm / Identity Store
>>>>>> Werner Keil: Authentication Store / Identity Store
>>>>>> Ajay Reddy: Identity Store / User Repository / Realm
>>>>>> Pedro Igor: Identity Store
>>>>>> Jean-Louis Monteiro: Authentication Store / Store
>>>>>>
>>>>>>
>>>>>> Organized per term:
>>>>>>
>>>>>> Identity Store - 5
>>>>>> Authentication Store - 3
>>>>>> Realm - 3
>>>>>> Store - 1
>>>>>> Security Provider - 1
>>>>>> User Repository - 1
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Louis Monteiro
>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>> http://www.tomitribe.com
>>>>>>>
>>>>>>> On Fri, Apr 10, 2015 at 12:22 AM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Fri, Apr 10, 2015 at 12:11 AM, Alex Kosowski
>>>>>>>> <alex.kosowski_at_oracle.com> wrote:
>>>>>>>>> I change my vote to just "Identity Store"
>>>>>>>>
>>>>>>>> Okay, so then we have:
>>>>>>>>
>>>>>>>> David Blevins: Store
>>>>>>>> Arjan Tijms: Authentication Store
>>>>>>>> Alex Kosowski: Identity Store
>>>>>>>> Rudy De Busscher: Security Provider
>>>>>>>> Darran Lofthouse: Realm / Identity Store
>>>>>>>> Werner Keil: Authentication Store / Identity Store
>>>>>>>> Ajay Reddy: Identity Store / User Repository / Realm
>>>>>>>> Pedro Igor: Identity Store
>>>>>>>>
>>>>>>>>
>>>>>>>> Organized per term:
>>>>>>>>
>>>>>>>> Identity Store - 5
>>>>>>>> Authentication Store - 2
>>>>>>>> Realm - 2
>>>>>>>> Store - 1
>>>>>>>> Security Provider - 1
>>>>>>>> User Repository - 1
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Arjan Tijms
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/9/15 5:56 PM, Pedro Igor Silva wrote:
>>>>>>>>>>
>>>>>>>>>> In PicketLink, IdentityStore is mainly related on how you manage
>>>>>>>>>> identities and relationships. Identities would be users, roles,
>>>>>>>>>> groups,
>>>>>>>>>> applications, etc. And relationships would be grants(rbac), group
>>>>>>>>>> membership(gbac) and so forth. It is basically a CRUD interface,
>>>>>>>>>> base
>>>>>>>>>> for
>>>>>>>>>> all others specific stores we have.
>>>>>>>>>>
>>>>>>>>>> Regarding authentication, there is also a specific store for
>>>>>>>>>> credentials,
>>>>>>>>>> the CredentialStore. There is a reference to it in the scope
>>>>>>>>>> document
>>>>>>>>>> as
>>>>>>>>>> follows:
>>>>>>>>>>
>>>>>>>>>> "4.3.c Credentials also in Identity Store? Perhap separate secured
>>>>>>>>>> store?"
>>>>>>>>>>
>>>>>>>>>> These two stores are involved during the authentication process.
>>>>>>>>>> Where
>>>>>>>>>> you
>>>>>>>>>> need to load an account (eg.: user) and authenticate based on a
>>>>>>>>>> specific
>>>>>>>>>> credential type (password, totp, X.509, token, etc).
>>>>>>>>>>
>>>>>>>>>> PermissionStore, on the other hand, is specific for permissions
>>>>>>>>>> and
>>>>>>>>>> is
>>>>>>>>>> not
>>>>>>>>>> related at all with authentication. Like you said, is related with
>>>>>>>>>> acl
>>>>>>>>>> authorization.
>>>>>>>>>>
>>>>>>>>>> I would say that in this case makes more sense Identity Store.
>>>>>>>>>> Specially
>>>>>>>>>> if you consider what Darran said about the potential to be widely
>>>>>>>>>> referenced
>>>>>>>>>> after authentication.
>>>>>>>>>>
>>>>>>>>>> One of the reasons for different and specific stores is that you
>>>>>>>>>> may
>>>>>>>>>> mix
>>>>>>>>>> different repositories (Eg.: LDAP and JPA), where each one can be
>>>>>>>>>> used
>>>>>>>>>> to
>>>>>>>>>> store only a specific type of information. For instance, use LDAP
>>>>>>>>>> for
>>>>>>>>>> users
>>>>>>>>>> and credentials, but JPA for more fine grained authorization with
>>>>>>>>>> permissions/acl. And also because each repository has its
>>>>>>>>>> limitations.
>>>>>>>>>> For
>>>>>>>>>> instance, It is really hard to support ACL or even custom
>>>>>>>>>> attributes
>>>>>>>>>> in
>>>>>>>>>> LDAP.
>>>>>>>>>>
>>>>>>>>>> Regards.
>>>>>>>>>> Pedro Igor
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Werner Keil"<werner.keil_at_gmail.com>
>>>>>>>>>> To: jsr375-experts_at_javaee-security-spec.java.net
>>>>>>>>>> Sent: Thursday, April 9, 2015 12:18:32 PM
>>>>>>>>>> Subject: [jsr375-experts] Re: 1-TerminologyAuthInteractionVsStore
>>>>>>>>>> ACTION:
>>>>>>>>>> cast vote
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Werner
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 9, 2015 at 5:08 PM, Werner Keil<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> 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>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Mar 23, 2015 at 10:32 PM, Alex Kosowski<
>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>