1 2 3 Previous Next 40 Replies Latest reply: Jan 15, 2007 8:14 AM by George Gastaldi RSS

Generalizing the JAAS and JACC service

Woodler Expert

a new start since the previous JACC thread got a bit lost in details (sorry for that)

What about a service that is the integration point for JAAS login modules and JACC Policies? In other words: there is a service that can be reached from the authentication and the policy decision point. This service has a pluggable architecture to delegate the authentication or authorization request to the actual identity provider, similar to a meta directory or virtual directory, with the exception that it is protocol agnostic. The plugin implementation encapulates the protocol. So the plugin could be a full blown IDP, or a simple proxy to an LDAP directory, etc.
From a server prospective, there would be a generic Login Module and a generic Policy that work together via the Subject. All the identity functionality is in this new IdentiyService.

The protocol between the appserver and the security service could be :
* whatever comes out of JSR196 for authentication
* XACML for authorisation (or perhaps a much simpler binary protocol ?)

....and if this sounds a lot like the M$'s IdentityMetaSystem, it's because it is ;)

  • 1. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

    I thought I replied to this a few days ago, but must not have hit the reply. I do like the MS security architecture around InfoCard and think we should look into it with JSR-196, WS-Trust, etc. in mind. I am not keen on having the primary identity representation be an actual JAAS subject as its a cumbersome class to use due to both its final nature and lack of direct access to its attributes.

    A related article on trust association interceptor integratin in websphere:
    http://www.theserverside.com/articles/article.tss?l=JAASAlternatives

  • 2. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    The first step would be to just look from the Authorization perspective.

    For people interested in the Microsoft Identity Metasystem/ecosystem, please read Kim Cameron's blog
    http://www.identityblog.com

  • 3. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    Martin,
    can we discuss the Portal JACC layer at:

    http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3907267


    Cheers,
    Anil

  • 4. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    To look at how Tomcat does Form based authentication, we can have a look at the source code for FormAuthenticator.java

    http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java

    As you can see, TC has some notion of SSO in this authenticator. Once the logic figures out that the Principal has not been established, then a redirection is made to the "login" page.

    Also the authenticator finally calls the Realm with the user name and password.

    So basically the authenticators have authorization decisions made at the end.

    org.apache.catalina.authenticator.AuthenticatorBase.java
    
    
    /**
     * Authenticate the user making this request, based on the specified
     * login configuration. Return <code>true</code> if any specified
     * constraint has been satisfied, or <code>false</code> if we have
     * created a response challenge already.
     *
     * @param request Request we are processing
     * @param response Response we are creating
     * @param config Login configuration describing how authentication
     * should be performed
     *
     * @exception IOException if an input/output error occurs
     */
     protected abstract boolean authenticate(Request request,
     Response response,
     LoginConfig config)
     throws IOException;
    


    The authentication/authorization is done by this method.

  • 5. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    I have the following wiki pages for supporting diagrams and design details, to supplement the design discussion on this thread.

    Next Generation Authentication Layer
    http://wiki.jboss.org/wiki/Wiki.jsp?page=GeneralizedAuthenticationLayer

    Next Generation Authorization Layer
    http://wiki.jboss.org/wiki/Wiki.jsp?page=GeneralizedAuthorizationLayer

    I am going to update these wiki pages with some details in the next day or two.

  • 6. Re: Generalizing the JAAS and JACC service
    Woodler Expert

    here is a new OASIS TC that might be of interest in this context:

    OASIS members have requested that we open a new discussion list,
    regarding a possible new OASIS Domain-Independent Policy Assertion Language
    (DIPAL) TC. Anyone who wishes to participate may do so by sending a message to dipal-discuss-subscribe@lists.oasis-open.org

    DISCUSSION LIST PROPOSAL

    The OASIS members listed below request that OASIS start a discussion list about a proposed TC for a "Domain-Independent Policy Assertion Language", in accordance with the OASIS TC Process document, Section 2.1 "TC Discussion Lists".

    The proposed DIPAL TC would develop a language that would layer on top of any Boolean web services policy framework, including WS-Policy. The intent would be to make it work with whatever becomes the standard policy framework, whether that is WS-Policy or something else. Therefore, this activity addresses a different layer in the policy processing stack from
    WS-Policy and is complementary to such a policy framework language.

    The required information is provided below:

    >> The name of the discussion list, which shall not be the same as the
    >> name of the list in which the TC itself shall operate if formed.

    dipal-discuss

    >> A preliminary statement of scope for the TC whose formation the list
    >> is intended to discuss.

    The scope envisioned for the proposed OASIS TC is the development of a
    domain-independent language for expressing policy assertions, along with
    semantics for verifying such assertions, comparing or intersecting
    assertions over the same policy item from two different policies, and
    selecting preferred values from a set of permitted values. The language
    would provide a generic way of expressing conditions that particular
    domain-specific policy items must satisfy.

    The language would be designed to express policy assertions for use with
    any Boolean web services policy framework. That is, the language would
    express assertions over individual policy vocabulary items, but combining these assertions into a policy expressing acceptable combinations and alternatives would be relegated to a framework layer. The development
    of a policy framework for combining individual policy assertions into policies is not within the proposed scope.

    The goal of the language is to facilitate interoperability and maintainability of web services policies. A single policy assertion module supporting this language should be able to verify, match, intersect, or perform preferred value selection using any assertions written in the language, from any domain. This means policy processors would not need new code modules for each new type of policy assertion that is required for a system or application. The policy framework may make use of policy assertions written in the domain-independent language as well as assertions written in other domain-specific languages.

    If the discussion list ended with a proposal to form a new OASIS TC, we
    envision the TC operating under the "RF (Royalty Free) on Limited Terms"
    IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy.
    We also anticipate that one of the input documents to the proposed TC would be the draft "XACML-based Web Services Policy Constraints Language (WS-PolicyConstraints)" specification authored by Sun Microsystems and offered on royalty-free terms. This draft specification is available at
    http://research.sun.com/projects/xacml/ws-policy-constraints-current.pdf

    >> The names, electronic mail addresses, and membership affiliations of
    >> the three or more Eligible Persons proposing to create the discussion list.

    Anne Anderson <Anne.Anderson@sun.com> (Sun Microsystems)
    Frank Siebenlist <franks@mcs.anl.gov> (Argonne National Labs)
    Jacques Durand <JDurand@us.fujitsu.com> (Fujitsu)
    Frederick Hirsch <Frederick.Hirsch@nokia.com> (Nokia)

    >> The name of the discussion list leader.

    Anne Anderson

  • 7. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    Added the class diagram for the JSR-196 specification......

    http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassDiagramJSR196

  • 8. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    Need some feedback on the following:

    As highlighted in the following wiki page:
    http://wiki.jboss.org/wiki/Wiki.jsp?page=GeneralizedAuthenticationLayer

    a ServerAuthModule may delegate part or majority of its auth decision making to a stack of login modules.

    Hence a configuration file that considers JSR196 should have a scope for plain authmodule configuration as well as serverauthmodule bridging into LoginModule stack.

    Hence the following configuration updates to the login-config.xml seems appropriate, with minimal intrusion into the existing SX framework, based on JAAS.

    Objective: Configuration File for JSR196 Based Framework, retaining the login-config.xml style of security domain configuration.

    This is the current outline of the login-config.xml file

    <application-policy name="security-domain-name">
     <authentication>
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     ...
     </authentication>
    </application-policy>
    


    I want to bring in the option of adding auth modules to the authentication
    element, as follows. This is in addition to the existing authentication element as shown above:


    
    <application-policy name="security-domain-name">
     <authentication>
     <login-module-stack name="login-stack-name">
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </login-module-stack>
     <auth-module code="auth.module1.class.name" type="client">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </auth-module>
    
     <auth-module code="auth.module2.class.name" type="server"
     login-module-stack="some-login-stack-name-1">
     ...
     </auth-module>
    
     <auth-module code="auth.module3.class.name" type="server"
     login-module-stack="some-login-stack-name-2">
     ...
     </auth-module>
     ...
     </authentication>
    </application-policy>
    


    Here we have defined reusable login-module-stacks within a particular security domain. Then the auth modules are defined pertaining to the domain, with the ability added to the ServerAuthModule(s) to bridge to a login-module-stack.

    I would like to prototype this configuration, if there are no objections.

    Please note that the discussion on generalized security service that is more advanced than the current JaasSecurityManagerService, with better caching abilities, federation and primary identity representation be a non-jaas-subject, will follow in a seperate discussion thread.

  • 9. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

    So JASPI appears to be missing the equivalent of the JAAS Configuration factory type methods. I would think we need to evolve the current configuration into one that can support either the JAAS Configuration or the JASPI. There should be two distinct application-policy child elements, the legacy JAAS authentication element, and a new authentication-jaspi element to allow for backward compatible evolution of the login-config.xml.

    Its not clear that the type="server|client" attribute is needed as it could be inferred from the module implementation, and I suppose its possible for the implementation to support both the ServerAuthModule and ClientAuthModule interfaces.

    It should be possible to only use JAAS login modules using the new authentication-jaspi so that the authentication element can be deprecated. For example:

    <application-policy name="security-domain-name">
     <authentication>
     <login-module-stack name="login-stack-name">
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </login-module-stack>
     <login-module-stack-ref ref="login-stack-name" />
     </authentication>
    </application-policy>
    
    


    Where the login-module-stack-ref element is an alias for a ServerAuthModule that delegates to the referenced login-module-stack. We would have a default implementation of such a delegating ServerAuthModule.


  • 10. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

     

    "scott.stark@jboss.org" wrote:
    So JASPI appears to be missing the equivalent of the JAAS Configuration factory type methods. I would think we need to evolve the current configuration into one that can support either the JAAS Configuration or the JASPI. There should be two distinct application-policy child elements, the legacy JAAS authentication element, and a new authentication-jaspi element to allow for backward compatible evolution of the login-config.xml.


    Yes, there is no explicit Configuration stipulations as in the JAAS world. The contract for the ServerAuthConfig is as follows, which is really a "do-whatever-you-want-config" type:
    package javax.security.auth.container;
    
    /**
     * <p>This interface describes a configuration of ServerAuthModules.</p>
     * <p>Implementations of this interface are created by the AuthContextFactory.
     * The factory produces ServerAuthConfig implementations for a given message
     * layer and URI. Each returned implementation may represent its internal module
     * configuration in a custom manner.</p>
     * <p>Callers pass an ServerAuthConfig instances to the AuthContextFactory to
     * obtain ServerAuthContext objects. The AuthContextFactory looks into the
     * ServerAuthConfig to determine the ServerAuthModules to be encapsulated in a
     * returned ServerAuthContext, which is then used to validate client requests
     * and to secure server responses.</p>
     */
    public interface ServerAuthConfig
    {
     /**
     * Get the message layer for this ServerAuthConfig.
     */
     public MessageLayer getMessageLayer();
    }
    
    



    "scott.stark@jboss.org" wrote:

    Its not clear that the type="server|client" attribute is needed as it could be inferred from the module implementation, and I suppose its possible for the implementation to support both the ServerAuthModule and ClientAuthModule interfaces. It should be possible to only use JAAS login modules using the new authentication-jaspi so that the authentication element can be deprecated.


    I was just being explicit when an human being reads the config file to distinguish between client and server modules. Yes, The modules can implement both the ServerAuthModule and ClientAuthModule interfaces. We will remove the type attribute.

    Also, the ServerAuthModules can delegate part (or all) of their processing to a loginmodule bridge.

    Here is the updated configuration file proposal:
    <application-policy name="security-domain-name">
     <authentication>
     <login-module-stack name="login-stack-name">
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </login-module-stack>
     <login-module-stack-ref ref="login-stack-name" />
     </authentication>
     <authentication-jaspi>
     <login-module-stack name="login-stack-name">
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </login-module-stack>
     <auth-module code="auth.module1.class.name">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </auth-module>
    
     <auth-module code="auth.module2.class.name"
     login-module-stack-ref="some-login-stack-name-1">
     ...
     </auth-module>
    
     <auth-module code="auth.module3.class.name" type="server"
     login-module-stack-ref="some-login-stack-name-2">
     ...
     </auth-module>
     ...
     </authentication-jaspi>
    </application-policy>
    


    The first authmodule config has no LM bridge. Second and third authmodules have LM bridge.


    Scott, from your previous post, I need some more details on what you said:
    <application-policy name="security-domain-name">
     <authentication>
     <login-module-stack name="login-stack-name">
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </login-module-stack>
     <login-module-stack-ref ref="login-stack-name" />
     </authentication>
    </application-policy>
    

    So, we are introducing the element <login-module-stack-name> and <login-module-stack-ref> to the already existing authentication element to aid deprecation? Am I getting this right?

  • 11. Re: Generalizing the JAAS and JACC service
    Scott Stark Master

     

    "anil.saldhana@jboss.com" wrote:

    So, we are introducing the element <login-module-stack-name> and <login-module-stack-ref> to the already existing authentication element to aid deprecation? Am I getting this right?


    Yes, I'm thinking that this aides in switching to the more general JASPI configuration without actually changing the authentication mechanism. Its a simple migration aide from the authentication element to the authentication-jaspi element. In actuality there really is not too much being saved as:

     <login-module-stack-ref ref="login-stack-name" />
    


    is just a shorthand for:
    <auth-module code="org.jboss.security.x.SomeDelegateToJaasModule"
     login-module-stack-ref="login-stack-name" />
    


    Maybe its better to just be explicit ant not introduce the login-module-stack-ref element.


  • 12. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    Thanks Scott for the clarification. I was just pointing out that the customer will have to migrate from:

    <application-policy name="security-domain-name">
     <authentication>
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </authentication>
    </application-policy>
    


    to

    <application-policy name="security-domain-name">
     <authentication>
     <login-module-stack name="login-stack-name">
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </login-module-stack>
     <login-module-stack-ref ref="login-stack-name" />
     </authentication>
    </application-policy>
    


    See the introduction of a <login-module-stack> element engulfing the sequential list of login modules plus an additional <login-module-stack-ref> element. That was what I was trying to get clarified.

    If the customer is asked to do this much, we might as well ask him to do <authentication-jaspi> migration directly.

    2nd Question:
    Anyway, for this effort, I am thinking of bringing in a new schema file "security-config_5_0.xsd" in server/src/resources/schema based off of the security-config_4_1.xsd Is this right? Our current login-config.xml is based off of the old dtd.

  • 13. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

     

    <application-policy name="security-domain-name">
     <authentication>
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </authentication>
     <authentication-jaspi>
     <login-module-stack name="login-stack-name">
     <login-module code="login.module1.class.name" flag="control_flag">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </login-module>
    
     <login-module code="login.module2.class.name" flag="control_flag">
     ...
     </login-module>
     </login-module-stack>
     <auth-module code="auth.module1.class.name">
     <module-option name = "option1-name">option1-value</module-option>
     <module-option name = "option2-name">option2-value</module-option>
     ...
     </auth-module>
    
     <auth-module code="auth.module2.class.name"
     login-module-stack-ref="some-login-stack-name-1">
     ...
     </auth-module>
    
     <auth-module code="auth.module3.class.name" type="server"
     login-module-stack-ref="some-login-stack-name-2">
     ...
     </auth-module>
     ...
     </authentication-jaspi>
    </application-policy>
    


    I am going to retain the configuration for JAAS authentication element as it is. In the jaspi element, we will look for explicit auth module configurations.

    Migrating customers will anyway look for help/examples of usage in wiki pages/user guides. So it should be fine to expect explicit authmodule config.

  • 14. Re: Generalizing the JAAS and JACC service
    Anil Saldhana Master

    JSR-196, ServerAuthModule-LoginModule Bridge Profile

    5.1 Processing Model
    The ServerAuthModule must create an instance of a javax.security.auth.login.LoginContext. If the ServerAuthModule passes a custom javax.security.auth.login.Configuration object to the constructor, then it also passes a custom value as the name input. If the ServerAuthModule does not pass a custom Configuration object to the constructor, then it must pass its own fully qualified class name as the name input. In this case, the configuration administrator must configure the relevant LoginModule objects in an entry for that class name, or must configure the LoginModule objects into the standard default entry called,
    other.


    The constructor for LoginContext with Configuration as argument is JDK5 or later, as shown:
    public LoginContext(String name, Subject subject,
     CallbackHandler callbackHandler,
     Configuration config)
     throws LoginException
    
     Instantiate a new LoginContext object with a name, a Subject to be authenticated, a CallbackHandler object, and a login Configuration.
     Since: 1.5
    


    So supporting passage of a Configuration object to the LoginContext in the delegating ServerAuthModule in JBoss will be JDK5 dependent. Hence we will not support it for the time being. The passage of a custom name will suffice. FYI.

1 2 3 Previous Next