4 Replies Latest reply on Feb 26, 2006 12:44 PM by Scott Stark

    FORM-Auth combined with Federated SSO

    Anil Saldanha Master

      This thread relates to the following JIRA issue:

      The generic problem here is to retain the regular auth processing(basic/form) while still having the flexibility of considering federated sso.

      The JIRA issue discusses the problems/tasks associated.

      Interested parties in this can provide design feedback, potential solutions and pointers to literature.

        • 1. Re: FORM-Auth combined with Federated SSO
          Anil Saldanha Master

          All the authenticators in Tomcat are retrofitted already with the concept of SSO. The AuthenticatorBase when it starts, looks for a valve that is an instanceof

          Look at:

          and the method start()

           public void start() throws LifecycleException {
           // Look up the SingleSignOn implementation in our request processing
           // path, if there is one
           Container parent = context.getParent();
           while ((sso == null) && (parent != null)) {
           if (!(parent instanceof Pipeline)) {
           parent = parent.getParent();
           Valve valves[] = ((Pipeline) parent).getValves();
           for (int i = 0; i < valves.length; i++) {
           if (valves instanceof SingleSignOn) {
           sso = (SingleSignOn) valves;
           if (sso == null)
           parent = parent.getParent();

          The issue is that there can only be one instance of SingleSignOn valve configured. ClusteredSingleSignOn written by Brian Stransberry works on this concept of a SSO valve.

          If you look at the contract defined by the SingleSignOn class, we can achieve a notion of delegated federated identity in the authenticators.
          /** Associate the specified single sign on identifier with the specified Session.**/
          associate(java.lang.String ssoId, Session session)
          /**Perform single-sign-on support processing for this request. **/
          invoke(Request request, Response response)
          /**Attempts reauthentication to the given Realm using the credentials associated with the single sign-on session identified by argument ssoId.**/
          reauthenticate(java.lang.String ssoId, Realm realm, Request request)
          /**Sets whether each request needs to be reauthenticated (by an Authenticator downstream in the pipeline) to the security Realm, or if this Valve can itself bind security info to the request, based on the presence of a valid SSO entry, without rechecking with the Realm**/
          setRequireReauthentication(boolean required)

          The nice thing about this SingleSignOn valve is that it has full access to the request object (implies headers and cookies) and can circumvent the regular authentication if needed, on availability of a federated security token.

          Also with the completion of external configuration of the authenticators and the availability of this SingleSignClass as a template, we should be able to retrofit the base authenticators for federated identity, with minimum invasion.

          I am going to spend some time test driving this SingleSignOn class.

          • 2. Re: FORM-Auth combined with Federated SSO
            Anil Saldanha Master

            The following settings in web.xml are not valid:


            The reason is that servlet spec 2.4 is strict about this:

            <xsd:element name="form-login-page" type="j2ee:war-pathType">
            The form-login-page element defines the location in the web
            app where the page that can be used for login can be
            found. The path begins with a leading / and is interpreted
            relative to the root of the WAR.

            And rightfully, Tomcat is strict on this:
            java.lang.IllegalArgumentException: Form login page http://localhost:8082/login.jsp must start with a '/'
             at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.
            java:2719) at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.
            java:2745) at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:106

            I am not sure if we had a discussion around checking this possibility.

            If we have to retrofit the form auth mechanism to redirect to an external identity provider etc, then the settings have to be external, maybe jboss-web.xml.....No real help from web.xml

            • 3. Re: FORM-Auth combined with Federated SSO
              chris griffith Expert

              I am not sure if this thread is still relavent, but here is my $.02 USD.

              First, I would say that if your Federated SSO IDP has it's own web-based login page then using FORM authentication method is not the way to go. Instead use a custom Authenticator that can be configured via the Context config with url of IDP.

              If, your IDP does not have it's own web-based login page then then you can use FormAuthenticator which already looks for an sso cookie before forwarding to login page if necessary.
              The login page then would be where you configure the IDP's url.

              Hope this makes sense and is even a little bit usefull, cgriffith

              • 4. Re: FORM-Auth combined with Federated SSO
                Scott Stark Master

                I think what Anil was trying to suggest was a way of integrating with a IDP login layer. This should be integrated with the application login logic rather than hijacked by the IDP, so yes its relevant and I think we agree.