Skip to content

Commit

Permalink
Merge pull request #150 from ggam/auth
Browse files Browse the repository at this point in the history
Proposed fix for #149
  • Loading branch information
arjantijms committed Oct 27, 2019
2 parents cca76fe + a3ae258 commit 365183e
Show file tree
Hide file tree
Showing 2 changed files with 6 additions and 6 deletions.
8 changes: 4 additions & 4 deletions spec/src/main/asciidoc/authenticationMechanism.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ In some cases (for example, username/password authentication) the interaction be

The Jakarta EE Platform already specifies mechanisms for authenticating users of web applications. The Jakarta Servlet Specification, version 4.0 [https://jakarta.ee/specifications/servlet/4.0/[SERVLET40]] specifies a declarative mechanism for configuring an application to provide BASIC, DIGEST, FORM, or CERT authentication, with authentication performed automatically by the container based on the application's configuration, which, in the case of FORM authentication, can include custom form pages.

In addition, [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]] specifies a general-purpose mechanism for securing messages sent between Jakarta EE clients and servers. Jakarta Authentication defines an SPI called _ServerAuthModule_, which enables development of authentication modules to handle any credential type, or engage in interaction of arbitrary complexity with clients and third parties. [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]] also defines the Servlet Container Profile, which specifies howJakarta Authentication mechanisms, including _ServerAuthModules_, are integrated with the servlet container.
In addition, [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]] specifies a general-purpose mechanism for securing messages sent between Jakarta EE clients and servers. Jakarta Authentication defines an SPI called _ServerAuthModule_, which enables development of authentication modules to handle any credential type, or engage in interaction of arbitrary complexity with clients and third parties. [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]] also defines the Servlet Container Profile, which specifies howJakarta Authentication mechanisms, including _ServerAuthModules_, are integrated with the servlet container.

While both existing mechanisms are important and useful, each has limitations from the point of view of an application developer. The servlet container's _login-config_ mechanism is limited to the _auth-method_ types defined by [https://jakarta.ee/specifications/servlet/4.0/[SERVLET40]] -- it doesn't support other credential types, or complex interactions with callers. It also relies on unspecified container mechanisms to associate identity stores with applications. There is no way for an application to ensure that callers are authenticated against the desired identity store, or, indeed, against _any_ identity store.

Expand Down Expand Up @@ -307,7 +307,7 @@ See also the description of _RememberMeIdentityStore_ in Chapter 3, "<<identityS

The _AutoApplySession_ annotation provides a way to declaratively enableJakarta Authentication _javax.servlet.http.registerSession_ behavior for an authentication mechanism, and automatically apply it for every request.

The _javax.servlet.http.registerSession_ property is described in Section 3.8.4 of [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]].
The _javax.servlet.http.registerSession_ property is described in Section 3.8.4 of [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]].

This annotation embodies the concept of a caller being authenticated over a series of multiple HTTP requests (together, a "session"). The built-in form-based authentication mechanisms use this same concept. It is therefore implicitly suggested, but not required, that the form-based authentication mechanisms use the backing interceptor for this annotation to establish and maintain their sessions.

Expand Down Expand Up @@ -430,7 +430,7 @@ public class LoginBacking {

==== SecurityContext.authenticate() Notes ====

Any _LoginToContinue_-annotated _HttpAuthenticationMechanism_, as well as the two built-in FORM authentication mechanisms, can be triggered via a call to the _SecurityContext.authenticate()_ method. This method is based on the _HttpServletRequest.authenticate()_ method, as defined by [https://jakarta.ee/specifications/servlet/4.0/[SERVLET40]], but has been extended to support additional functionality defined by the Servlet Container Profile of [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]].
Any _LoginToContinue_-annotated _HttpAuthenticationMechanism_, as well as the two built-in FORM authentication mechanisms, can be triggered via a call to the _SecurityContext.authenticate()_ method. This method is based on the _HttpServletRequest.authenticate()_ method, as defined by [https://jakarta.ee/specifications/servlet/4.0/[SERVLET40]], but has been extended to support additional functionality defined by the Servlet Container Profile of [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]].

The extended behavior is facilitated by the _AuthenticationParameters_ parameter passed to _SecurityContext.authenticate()_. _AuthenticationParameters_ includes a _newAuthentication_ field.

Expand Down Expand Up @@ -464,7 +464,7 @@ httpMessageContext.getHandler().handle(new Callback[] {

An _HttpAuthenticationMechanism_ is a CDI bean, as defined by Jakarta Contexts and Dependency Injection spec, version 2.0 [https://jakarta.ee/specifications/cdi/2.0/[CDI20]].

The methods defined by the _HttpAuthenticationMechanism_ closely map to the methods and semantics of a _ServerAuthModule_, as defined by the Servlet Container Profile of [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]]. (But an _HttpAuthenticationMechanism_ is itself not a _ServerAuthModule_.) The servlet container MUST useJakarta Authentication mechanisms to arrange for an _HttpAuthenticationMechanism_ to be placed in service.
The methods defined by the _HttpAuthenticationMechanism_ closely map to the methods and semantics of a _ServerAuthModule_, as defined by the Servlet Container Profile of [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]]. (But an _HttpAuthenticationMechanism_ is itself not a _ServerAuthModule_.) The servlet container MUST useJakarta Authentication mechanisms to arrange for an _HttpAuthenticationMechanism_ to be placed in service.

This specification mandates that when a _ServerAuthModule_ is called by the Servlet container, CDI services (such as the _BeanManager_) MUST be fully available, and all scopes that are defined to be active during the _service()_ method of a servlet, or during the _doFilter()_ method of a servlet filter, MUST be active. Specifically this means that the request, session, and application scopes MUST be active, and that a _ServerAuthModule_ method such as _validateRequest()_ MUST be able to obtain a reference to the CDI _BeanManager_ programmatically (for example, by doing a JNDI lookup), and MUST be able to use that reference to obtain a valid request-scoped, session-scoped, or application-scoped bean. This specification does not mandate that a _ServerAuthModule_ must itself be a CDI bean, or that a _ServerAuthModule_ must be injectable.

Expand Down
4 changes: 2 additions & 2 deletions spec/src/main/asciidoc/bibliography.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -19,11 +19,11 @@ https://jakarta.ee/specifications/enterprise-beans/3.2/
Jakarta Expression Language, version 3.0 +
https://jakarta.ee/specifications/expression-language/3.0/

[JACC]::
[AUTHORIZATIONSPEC]::
Jakarta Authorization, version 1.5 +
https://jakarta.ee/specifications/authorization/1.5/

[JASPIC]::
[AUTHENTICATIONSPEC]::
Jakarta Authentication, version 1.1 +
https://jakarta.ee/specifications/authentication/1.1/

Expand Down

0 comments on commit 365183e

Please sign in to comment.