Darran Lofthouse created WFLY-10777: --------------------------------------- Summary: Add WildFly Elytron / JASPIC 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 Fix For: 14.0.0.CR1 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.5.0#75005)