|
9 | 9 | // |
10 | 10 | // Specification: JSR-375 Java EE Security API ("Specification") |
11 | 11 | // Version: 1.0 |
12 | | -// Status: Early Draft Review |
13 | | -// Release: March 2017 |
| 12 | +// Status: Public Review |
| 13 | +// Release: May 2017 |
14 | 14 | // |
15 | 15 | // Copyright 2017 Oracle America, Inc. |
16 | 16 | // 500 Oracle Parkway, Redwood City, California 94065, U.S.A. |
|
141 | 141 |
|
142 | 142 | [[concepts]] |
143 | 143 |
|
144 | | -== Concepts |
| 144 | +== Concepts and General Requirements |
145 | 145 |
|
146 | | -* authentication |
147 | | -* authorization |
148 | | -* credential |
149 | | -* jaspic |
150 | | -* java servlet specification |
151 | | -* token |
| 146 | +This chapter overview information and terminology related to this specification, and also includes a general requirements not specified elsewhere in this document. |
| 147 | + |
| 148 | +=== Terminology And Acronyms |
| 149 | + |
| 150 | +A common understanding of security-related terms is helpful for discussion or specification of security APIs. To that end, we incorporate by reference the excellent https://shiro.apache.org/terminology.html[Apache Shiro Terminology], and define some additional terms used in this document. |
| 151 | + |
| 152 | +Authentication Mechanism :: |
| 153 | +The mechanism by which authentication is performed. This mechanism interacts with the caller to obtain credentials and invokes an identity store to match the given credentials with a known user (identity). If a match is found, the Authentication Mechanism uses the found identity to populate attributes (principals) to build an authenticated Subject. If a match is not found, the Authentication Mechanism reports a failed authentication, the caller is not logged in, and is unable to be given authorization. |
| 154 | + |
| 155 | +Caller, Caller Principal:: |
| 156 | +A caller is a user that is making a request to an application, or invoking an application API. A Caller Principal is a Principal object representing that user. This specification uses the term caller in preference to the term user in most contexts. |
| 157 | + |
| 158 | +HAM:: |
| 159 | +Abbreviation for _HttpAuthenticationMechanism_, an interface defined by this specification. |
| 160 | + |
| 161 | +Identity Store:: |
| 162 | +An Identity Store is a component that can access application-specific security data such as users, roles, and permissions. It can be thought of as a security-specific DAO (Data Access Object). Synonyms: security provider, repository, store, login module (JAAS), identity manager, service provider, relying party, authenticator, user service. Identity Stores usually have a 1-to-1 correlation with a data source such as a relational database, LDAP directory, file system, or other similar resource. As such, implementations of the _IdentityStore_ interface use data source-specific APIs to discover authorization data (roles, permissions, etc), such as JDBC, File IO, Hibernate or JPA, or any other Data Access API. |
| 163 | + |
| 164 | +JASPIC:: |
| 165 | +Java Authentication SPI for Containers. |
| 166 | + |
| 167 | +SAM:: |
| 168 | +Abbreviation for _ServerAuthModule_, an interface defined by JASPIC. |
| 169 | + |
| 170 | +=== General Requirements |
| 171 | + |
| 172 | +The following general requirments are defined by this specification. |
| 173 | + |
| 174 | +==== Group-To-Role Mapping |
| 175 | + |
| 176 | +Various Java EE specifications define how roles are declared for an application, and how access to application resources can be restricted to users that have a specific role. The specifications are largely silent on the question of how users are assigned to roles, however. Most application servers have proprietary mechanisms for determining the roles a user has. |
| 177 | + |
| 178 | +Application servers MUST provide a default mapping from group names to roles. That is, a caller who is a member of group "foo" is considered to have role "foo". This default mapping MAY be overridden by proprietary configuration, but, when not overridden, provides sensible and predictable behavior for portable applications. |
| 179 | + |
| 180 | +An application MAY provide a default mapping from caller principal names to roles. That is, a caller with the name "bar" is considered to have role "bar". This default mapping MAY be overridden by proprietary configuration. |
| 181 | + |
| 182 | +==== Caller Principal Types |
| 183 | + |
| 184 | +This specification defines a principal type called _CallerPrincipal_ to represent the identity of an application caller. Historically, application servers have used different principal types to represent an application's callers, and various Java EE specifications (e.g., JASPIC), provide abstractions to accomodate, "the container's representation of the caller principal". |
| 185 | + |
| 186 | +This specification RECOMMENDS that Java EE application servers that rely on container-specific caller principal types derive those types by extending _CallerPrincipal_, so that portable applications can rely on a consistent representation of the caller principal. |
0 commit comments