[jboss-jira] [JBoss JIRA] (WFLY-10777) Add WildFly Elytron / JASPI Integration Tests

[James Perkins (Jira)]

     [ https://issues.jboss.org/browse/WFLY-10777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-10777:
---------------------------------
    Fix Version/s: 15.0.0.Final


> Add WildFly Elytron / JASPI Integration Tests
> ---------------------------------------------
>
>                 Key: WFLY-10777
>                 URL: https://issues.jboss.org/browse/WFLY-10777
>             Project: WildFly
>          Issue Type: Task
>          Components: Security, Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Major
>             Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> The following key scenarios should be covered within the Elytron testsuite module: -
> * Pre-configured JASPIC
> In this case the SAMs are configured within the Elytron subsystem and applied at runtime to the web application.
> Two predominant modes to consider: -
> # Fully integrated, i.e. the Callbacks make use of the SecurityDomain for authentication.
> # Ad-Hoc Identity i.e. We still have a security domain but trust the SAM to establish an ad-hoc identity.
> * Programatically configured JASPIC
> During servlet initilisation the new JaspicConfigurationBuilder API can be used to dynamically register a configuration.
> Likely to need the same two modes.
> * Retrospective JASPIC
> In both the above cases the deployment can be deployed and either use Elytron HTTP authentication mechanisms or be unsecured, JASPIC for the deployment can be activated either via configuration or programatically and should take precedence over the existing authentication.
> * Programatic Authentication
> A servlet can use the authentication API on the HttpServletRequest and trigger authentication.
> * No SecurityDomain
> This one may not be as applicable at this stage but we should at some point support JASPIC being applied to a deployment not associated with any security domain, i.e. a new deployment on a clean install could programatically register a JASPIC configuration.
> Without any security domain the identity would only have relevance within the servlet container so establishing an ad-hoc identity is actually a better approach.  Additionally this relies on no default being present in the default config.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)