[jboss-jira] [JBoss JIRA] (WFLY-9212) Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object, Subject)

[Scott Stark (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-9212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446591#comment-13446591 ] 

Scott Stark edited comment on WFLY-9212 at 8/9/17 2:08 PM:
-----------------------------------------------------------

For completeness, the complete workaround also requires reestablishing the roles from the authenticated subject, so that code snippets are:


{code:java}
// Workaround authenticated JWTPrincipal not being installed as user principal
// https://issues.jboss.org/browse/WFLY-9212
org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
Subject subject = jbSC.getUtil().getSubject();
jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
RoleGroup roles = extract(subject);
jbSC.getUtil().setRoles(roles);

    /**
     * Extract the Roles group and return it as a RoleGroup
     * @param subject authenticated subject
     * @return RoleGroup from "Roles"
     */
    protected RoleGroup extract(Subject subject) {
        Optional<Principal> match = subject.getPrincipals()
                .stream()
                .filter(g -> g.getName().equals(SecurityConstants.ROLES_IDENTIFIER))
                .findFirst();
        Group rolesGroup = (Group) match.get();
        RoleGroup roles = new SimpleRoleGroup( rolesGroup );
        return roles;
    }
{code}



was (Author: starksm64):
For completeness, the complete workaround also requires reestablishing the roles from the authenticated subject, so that code snippets are:


{code:java}
                        // Workaround authenticated JWTPrincipal not being installed as user principal
                        // https://issues.jboss.org/browse/WFLY-9212
                        org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
                        Subject subject = jbSC.getUtil().getSubject();
                        jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
                        RoleGroup roles = extract(subject);
                        jbSC.getUtil().setRoles(roles);

    /**
     * Extract the Roles group and return it as a RoleGroup
     * @param subject authenticated subject
     * @return RoleGroup from "Roles"
     */
    protected RoleGroup extract(Subject subject) {
        Optional<Principal> match = subject.getPrincipals()
                .stream()
                .filter(g -> g.getName().equals(SecurityConstants.ROLES_IDENTIFIER))
                .findFirst();
        Group rolesGroup = (Group) match.get();
        RoleGroup roles = new SimpleRoleGroup( rolesGroup );
        return roles;
    }
{code}


> Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object,Subject)
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9212
>                 URL: https://issues.jboss.org/browse/WFLY-9212
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 10.1.0.Final
>            Reporter: Scott Stark
>            Assignee: Darran Lofthouse
>
> I have a custom JWT based auth method and JAAS login module that I'm testing with swarm which is using WFLY 10.1.0.Final. I am not able to install a custom Principal instance for retrieval via the JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() because of how the JAASIdentityManagerImpl#verifyCredential(final AccountImpl account, final Object credential) method populates the SecurityContext.SecurityContextUtil SubjectInfo.
> The following line:
> https://github.com/wildfly/wildfly/blob/c3332cec0c9bc5dc57899c2ae7ba26dd0c627686/undertow/src/main/java/org/wildfly/extension/undertow/security/JAASIdentityManagerImpl.java#L130
>                 sc.getUtil().createSubjectInfo(incomingPrincipal, credential, subject);
> Is using the incomingPrincipal, which is derived from the simple AccountImpl wrapping of the incoming String id. In my call path, this is the user id before any authentication has happened as there is no originalPrincipal value on the AccountImpl, so it is not the best representation of the authenticated caller, and the wrapping Principal instance does not exist amongst the authenticated Subject#getPrincipals().
> I see this is due to a CallerPrincipal issue:
> https://issues.jboss.org/browse/WFLY-3626
> but one needs to be able to control what form of the authenticated userPrincipal that is returned by the  user face container getUserPrincipal() call
> See the getPrincipalClass() unit test in this repo for an example of what is being tested:
> https://github.com/MicroProfileJWT/microprofile-jwt-auth-wfswarm/blob/f39537db573ea813559548bc42d74ef1f581024f/src/test/java/org/eclipse/microprofile/jwt/test/jaxrs/RolesAllowedTest.java#L169
> I can work around this by overriding the SubjectInfo by immediately after the auth mechanism has called the SecurityContext#authenticationComplete(...) using:
> // Workaround authenticated JWTPrincipal not being installed as user principal
> org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
> Subject subject = jbSC.getUtil().getSubject();
> jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
> I have tried wrapping the Account passed into SecurityContext#authenticationComplete(...) and that has not worked so far, but I'll look again to see if there is something else I can override to achieve the desired behavior.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)