Page tree

The Shibboleth 2.x software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP30 and SP3 wiki spaces for current documentation on the supported versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Problem

You would like to enable Container-Managed Authentication in a Java EE web application fronted by a Shibboleth Native SP, in order to, for instance, leverage the platform's authorization capabilities, such as the EJB security model, from within your application's code. Your Application Server (AS) is, however, unaware of authentication performed by Shibboleth, effectively treating your users as anonymous. Thus, such API calls do not typically work right out of the box. What needs to be done is to somehow propagate the user identity at the SP to the AS, or in simple terms, a "caller" Principal representing the authenticated user needs to be established at there.

Solution

In order to communicate the fact that a user should be considered authenticated to your AS, you may either implement a container-specific JAAS LoginModule, or what is loosely termed its standard, Java EE counterpart, a JASPIC ServerAuthModule (SAM) . This how-to employs the standardized over the proprietary approach.

Assumptions

  • Your SP your application's resources.
  • Your AS is an implementation of the Full Java EE 6+ Profile.
  • Your application comprises both "protected" and "public" resources.

Implement the SAM

SAMs

SAMs closely resemble the functionality (e.g. manipulation or blocking of HttpServletRequests and HttpServletResponses) provided by common Servlet Filters; they may in fact be implemented as such. Unlike a Filter, however, a SAM is always invoked before the first FilterChain's Filter, it is used by potentially multiple applications and is capable of communicating authentication decisions to the AS.

The following example is a simplistic "bridge" SAM, which, for every --which is obviously not ideal-- incoming request:

  1. Probes the received HttpServletRequest for presence of the "eduPersonPrincipalName" and "eduPersonAffiliation" attributes.
  2. If both are present, registers a "caller" Principal and one or multiple "group" Principals --enclosing the values of "eduPersonPrincipalName" and "eduPersonAffiliation" as their respective names-- at the AS to represent the authenticated user.
  3. Otherwise:
    1. If the targeted request is "public", it treats the user as a guest.
    2. Otherwise, it redirects the request to the SP's SessionInitiator.

Step 3.b. also occurs whenever the user explicitly asks to be authenticated, e.g. by clicking a "Login" button in the UI. Similarly, when the user wishes to be logged out, the SAM redirects her request to the SP's LogoutInitiator.

SpAsBridgeSam.java
public class SpAsBridgeSam implements ServerAuthModule {
}

 

Step-by-step guide

1 Java EE mostly disregards javax.security.auth.Subjects; all what's left of them, that is, what most Java EE specifications tend to use, is this one "caller" Principal, along with potential "group" Principals. A blog entry by Arjan Tijms titled "JAAS in Java EE is not the universal standard you may think it is" examines some common misconceptions surrounding JAAS in this scope.

2 JSR 196, Authentication Service Provider Interface for Containers (JASPIC, JASPI) is available in the Full Java EE 6+ Profile, and Servlet 3+ Containers included in compatible implementations, have been mandated to support JASPIC's Servlet Profile.

 

  • No labels