I'm trying to implement SAML auth for PASOE, and seeing a problem I don't know how to solve.
The SAML token contains an attribute called "Roles", and I want PASOE to put all of those roles into the Client Principal. However, it seems to only want to pick the first role in the list and use that one in the CP. In my testing, my SAML token has 3 roles listed in it, but my CP only ends up with the first one.
Oddly, I can still see the other roles if I do Get-Property("Roles") on the CP, so I know PASOE is reading them.
Here's what my oeablSecurity.properties looks like:
## SAML UserDetails
## Usually roles comes as part of asseration attribute of SAML token
## If there roles are configured with multiple attributes then use comma separated list of attributes
samlToken.UserDetails.roleAttrName=Roles
## If there is not roles found in SAMl token then use default roles as PSCUser
samlToken.UserDetails.defaultGrantedAuthorities=ROLE_PSCUser
samlToken.UserDetails.rolePrefix=
samlToken.UserDetails.userDomain=mydomain
samlToken.UserDetails.registryFile=ABLDomainRegistry.keystore
A section from the log file where the SAML is being parsed:
09:46:00.861/196079 [thd-10] DEBUG c.p.a.s.s.OEAuthenticationTokenConverter - Inserting ClientPrincipal property org.opensaml.saml2.core.impl.AttributeImpl@4d41adb8 with value: myapp.submitter.all,myapp.all,myapp.pricer.all,
09:46:00.861/196079 [thd-10] DEBUG c.p.a.s.s.OEAuthenticationTokenConverter - Inserting ClientPrincipal account info
09:46:00.861/196079 [thd-10] DEBUG c.p.a.s.s.OEAuthenticationTokenConverter - Loading Spring authorities ...
09:46:00.861/196079 [thd-10] DEBUG c.p.a.s.s.OEAuthenticationTokenConverter - Loading Spring authority : myapp.submitter.all
09:46:00.861/196079 [thd-10] DEBUG c.p.a.s.s.OEAuthenticationTokenConverter - Inserting ClientPrincipal roles: PSCUser,myapp.submitter.all
09:46:00.861/196079 [thd-10] DEBUG c.p.a.s.s.OEAuthenticationTokenConverter - Sealing ClientPrincipal token (R)
09:46:00.862/196080 [thd-10] DEBUG c.p.a.s.s.OEAuthenticationTokenConverter - Cloning Spring token with ClientPrincipal
09:46:00.862/196080 [thd-10] DEBUG c.p.a.s.s.OEClientPrincipalFilter - Replaced SecurityContextHolder with OEAuthenticationToken: from 'org.springframework.security.providers.ExpiringUsernameAuthenticationToken@f0c87ebf: Principal: myuser@mycompany.com; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.core.userdetails.User@df456d93: Username: myuser@mycompany.com; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: myapp.submitter.all; Granted Authorities: myapp.submitter.all'
09:46:00.862/196080 [thd-10] DEBUG c.p.a.s.s.OEClientPrincipalFilter - Inserting OpenEdge CCID header(request): id57119099417318921533599070
09:46:00.870/196088 [thd-10] DEBUG o.s.s.w.a.ExceptionTranslationFilter - Chain processed normally
09:46:00.870/196088 [thd-10] DEBUG c.p.a.services.security.OEMdcFilter - Request user-id attr already set at end of request: nullUser
09:46:00.870/196088 [thd-10] DEBUG c.p.a.services.security.OEMdcFilter - Update request user-id source is: nullUser
09:46:00.870/196088 [thd-10] DEBUG c.p.a.services.security.OEMdcFilter - MDC UID policy NEVER is not changing request user-id from Spring token type
09:46:00.870/196088 [thd-10] DEBUG c.p.a.s.s.OESamlWebSSOProcessingFilter - Authentication success. Updating SecurityContextHolder to contain: org.springframework.security.providers.ExpiringUsernameAuthenticationToken@f0c87ebf: Principal: myuser@mycompany.com; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.core.userdetails.User@df456d93: Username: myuser@mycompany.com; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: myapp.submitter.all; Granted Authorities: myapp.submitter.all
Is this a bug, or am I missing something from my config to tell PAS that I want ALL of the incoming groups to be in the CP?
As a workaround, I think I could probably clone the CP, add the roles from the first CP's attribute roles, and then re-sign it, but there's got to be a better way, right?
Steve,
I looks like a bug to me.
The fist highlighted line is inserting the SAML token's roles into a CP Property. If you dump the CP's property list from your ABL application you should see them.
The second highlighted line shows that when generating the CP, it only picked up the first item of the SAML token's roles.
Cloning an resealing a CP is probably not a good idea long-term.
Mike J.