]
Guillermo González de Agüero updated WFLY-5739:
-----------------------------------------------
Attachment: CustomAuth.zip
picketbox.zip
Hi [~stoty2], I've tested the patch and I confirm it works. However, it still
doesn't restore groups
for a given CallerPrincipalCallback called with a principal stored from an earlier request
(enabling "javax.servlet.http.registerSession").
To reproduce, compile and deploy CustomAuth war. Update PicketBox module with my attached
picketbox.zip (compiled from your GH commit) and follow the steps below:
- Go to /index.jsp and you'll see a login form. Enter anything and a page with the the
specified name will be shown. Do a GET request and you'll see the roles are restored.
- You'll be able to see /protected.jsp, which requires "admin" role.
- Now go to /TestServlet. A NullPointerException will be shown, cause groups are not
restored.
- Going to /TestServlet?username=Guillermo correctly propagates roles thanks to your
patch.
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}