Hi guys,
Thanks for the update, this sounds like really good progress!
On Tue, May 26, 2015 at 4:09 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
> On the details, what I attempted to convey was that imv JSR 375 is looking
> for a place for applications
> to store, or package authentication information for "their users", i.e.,
> usernames, passwords, and
> role memberships. It is also looking for interfaces that applications can
> use to manage this info.
>
Basically yes. The EG just voted on calling such place "identity store" (as
working term at least).
Having that identity store as part of the application and acknowledging it
can be about "their users" is an important design consideration.
However, in my opinion such store should transparently work when installed
at the container level as well. Obviously the method to install and likely
configure such store is server specific when installed at the container
level, but it should be the same interface.
At the same time there was a request to standardize a few common
implementations of the identity stores, such as ones for LDAP, Database and
file (users.xml/roles.xml). Nearly every server has these I think. This is
e.g. an example for Resin:
http://caucho.com/resin-4.0/admin/security-overview.xtp#Authenticators
> I suggested that what I saw being discussed in JSR 375, seemed more like a
> standardization of the concept of realm, as seen in the various forms in
> the various EE containers,
>
Exactly, with the caveat that "realm" is but one term the various EE
containers use for this concept. At least the following terms are also used
for the exact same concept:
- security provider (WebLogic)
- user registry (WebSphere/Liberty) (explanation uses term "account
repository")
- realm (Tomcat, some hints in Servlet spec)
- login module (JAAS)
- authenticator (Resin, OmniSecurity, Seam Security)
- authentication repository
- authentication store
- authentication provider (Spring Security)
- identity manager (Undertow)
- identity provider
- identity store
- service provider
- relying party
- user service
Kind regards,
Arjan Tijms