Analysis / Design - JASPIC Integration with WildFly Elytron

Version 4

    Analysis

     

    Summary

    The current JASPIC implementation within WildFly is based on the integration with the legacy PicketBox security SPIs, this task is to provide a clean JASPIC integration with WildFly Elytron.  Additionally JSR-375 will be build on JASPIC, the JSR-375 implementation will be included as it's own task but the clean JASPIC implementation should take into account what is coming.

     

    Requirements

     

    The JASPIC specification can be found under JSR-196

     

    Once complete it should be possible to make use of JASPIC with no reference to or configuration in the legacy security subsystem.

     

    Design Notes

    Existing Implementation

    Within the legacy security subsystem JASPIC related configuration is associated with the security domain.

     

                    <security-domain name="jaspitest" cache-type="default">
                        <authentication-jaspi>
                            <login-module-stack name="dummy">
                                <login-module code="Dummy" flag="optional"/>
                            </login-module-stack>
                            <auth-module code="Dummy"/>
                        </authentication-jaspi>
                    </security-domain>
    

    This implementation was only usable with the servlet profile as well as the login module profile.

     

    As a web application is deployed a reference to the SecurityDomain is obtained, if that security domain contains JASPIC configuration then JASPIC will be enabled for the web application - if no configuration is present then JASPIC will not be enabled at all for the web application.  This is contrary to the JASPIC specification where the decision to use JASPIC or not should be decided based on a call to https://docs.oracle.com/javaee/7/api/javax/security/auth/message/config/AuthConfigFactory.html#getConfigProvider-java.lang.String-java.lang.String-javax.security.auth.message.config.RegistrationListener-

     

    Applications that wish to use JASPIC but not backed by a security domain configuration are forced to use a dummy domain like the example configuration for it to be enabled.

     

    The default AuthConfigFactory if no other is registered is org.jboss.security.auth.message.config.JBossAuthConfigFactory, mappings can be added to this but by default at the time of authentication if there is no new match then an instance of org.jboss.security.auth.message.config.JBossAuthConfigProvider is returned.  The JBossAuthConfigProvider works by obtaining the current SecurityContext and from this obtaining the SecurityDomain and from there accessing the JASPIC configuration on the domain.

     

    Overall although a JASPIC configuration can be enabled it does not match the behaviour as defined in the specification.

     

    Comments: -

    • Specification says getConfigProvider() can be called and cached at deployment time but current impl does call it for each request IF JASPIC was at least discovered at the time of deployment.

     

     

     

     

     

     

    Prior implementations handled JASPIC as a specific authentication mechanism, this had a side effect that changes specifically made for JASPIC would impact the other mechanism handling and subsequently updates for the other mechanisms would impact JASPIC - integrating WildFly Elytron changes were made to Undertow to make it easier to take full control of the security handlers, my intention is to keep the JASPIC integration as independent as possible to minimise requirement conflicts.

     

    Comments captured against prior implementation JASPIC implementation issues · GitHub

     

    General

     

    Tracking Issues

     

    Main Tracking Issue - WFLY-9067

     

     

     

    Developer Resources

     

     

    Developer Contacts

     

    Darran Lofthouse - darran.lofthouse@jboss.com