Thanks. As long as there's no misconception with the dedicated Identity
JSR, it sounds fine to me.
Werner
On Thu, Apr 9, 2015 at 5:56 PM, Pedro Igor Silva <psilva_at_redhat.com> 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
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >
>