[Progress Communities] [Progress OpenEdge ABL] Forum Post: PASOE SAML Auth: Bug with getting roles into CP?

Status
Not open for further replies.
S

ssouthwe

Guest
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?

Continue reading...
 
Status
Not open for further replies.
Top