[
https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin....
]
István Tóth commented on WFLY-5739:
-----------------------------------
Hello [~ggam] !
Thank you for your answer and the test case!
After looking at the problem some more, I have come to understand the following:
There are at least three mechansisms/places for storing the group/roles data:
* in JbossSecurityContext (used by most of WildFly, including EJBs)
* in the Subject's ROLES_IDENTIFIER principal (used at least by JACC, and also gets
copied to to JbossSecurityContext)
* in the Undertow Account obejct (used by undertow, I guess)
JASPICallbackHandler.java in Picketbox only fills in the JbossSecurityContext.
JASPICAuthenticationMechanism.java in wildfly copies it to the Account, and optionally
caches it.
My original PR tried to fix the JACC roles in picketbox's JASPICallbackHandler.java.
However, due to registerSession feature, this bug cannot be fixed in Picketbox alone.
Instead of making essentially the same fix to two projects, I have tried a different
approach, and chose to leave picketbox alone, and instead copy the group information to
the ROLES_IDENTIFIER principal in wildfly's JASPICAuthenticationMechanism.java, where
the group information is available both during full authentication, and registersession
cached authentication.
I am hesitant to turn this into a pull request yet. Could you take a look at
https://github.com/stoty/wildfly/commits/WFLY-5739 and tell me if it's a valid
approach ?
Subject not populated with groups/roles when authenticated via
JASPIC
---------------------------------------------------------------------
Key: WFLY-5739
URL:
https://issues.jboss.org/browse/WFLY-5739
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 10.0.0.CR4
Reporter: Arjan t
Assignee: Darran Lofthouse
Labels: jacc, jaspic
Attachments: CustomAuth.zip, picketbox.zip
After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and
then using that for permission checks fails.
For instance the following code will always set {{hasAccess}} to false given that
"/protected/*" requires a role and the authenticated user is in that role:
{code:java}
Subject subject = (Subject)
PolicyContext.getContext("javax.security.auth.Subject.container");
boolean hasAccess = Policy.getPolicy().implies(
new ProtectionDomain(
new CodeSource(null, (Certificate[]) null),
null, null,
subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
),
new WebResourcePermission("/protected/Servlet", "GET"))
;
{code}
As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does
not contain the roles.
This can be traced back to
{{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes
clear that the roles are only put into the "util", but not in the
"authenticatedSubject":
{code:java}
String[] rolesArray = groupPrincipalCallback.getGroups();
int sizeOfRoles = rolesArray != null ? rolesArray.length : 0;
if( sizeOfRoles > 0 )
{
List<Role> rolesList = new ArrayList<Role>();
for( int i = 0; i < sizeOfRoles ; i++ )
{
Role role = new SimpleRole( rolesArray[ i ] );
rolesList.add( role );
}
RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList
);
// if the current security context already has roles, we merge them with the incoming
roles.
RoleGroup currentRoles = currentSC.getUtil().getRoles();
// *** ROLES ARE ONLY SET HERE ***
if (currentRoles != null) {
currentRoles.addAll(roles.getRoles());
}
else {
currentSC.getUtil().setRoles( roles );
}
}
// *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE
// *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO
Subject subject = groupPrincipalCallback.getSubject();
if( subject != null )
{
// if the current security context already has an associated subject, we merge it with
the incoming subject.
Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject();
if (currentSubject != null) {
subject.getPrincipals().addAll(currentSubject.getPrincipals());
subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials());
subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials());
}
currentSC.getSubjectInfo().setAuthenticatedSubject(subject);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)