Analysis / Design - JASPIC Integration with WildFly Elytron

Version 4




    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.




    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">
                            <login-module-stack name="dummy">
                                <login-module code="Dummy" flag="optional"/>
                            <auth-module code="Dummy"/>

    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


    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, mappings can be added to this but by default at the time of authentication if there is no new match then an instance of 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




    Tracking Issues


    Main Tracking Issue - WFLY-9067




    Developer Resources



    Developer Contacts


    Darran Lofthouse -