I need to transform principal before get attributes.
I'm using CAS 6.1 and the class that creates the Principal is: PersonDirectoryPrincipalResolver (https://github.com/apereo/cas/blob/6.1.x/core/cas-server-core-authentication-api/src/main/java/org/apereo/cas/authentication/principal/resolvers/PersonDirectoryPrincipalResolver.java).
How can I transform the principal? There is a "principalNameTransformer" attribute but I don't know how to configure it.
Per CAS documentation,
Authentication handlers that generally deal with username-password credentials can be configured to transform the user id prior to executing the authentication sequence. Each authentication strategy in CAS provides settings to properly transform the principal.
This means for a given authentication handler/scheme, you can find a reference in the properties guide such as:
Principal transformation settings for this feature [meaning authentication handler] are under the configuration key cas.authn.file.
...and available properties are here:
# ${configurationKey}.principalTransformation.pattern=(.+)#example.org
# ${configurationKey}.principalTransformation.groovy.location=file:///etc/cas/config/principal.groovy
# ${configurationKey}.principalTransformation.suffix=
# ${configurationKey}.principalTransformation.caseConversion=NONE|UPPERCASE|LOWERCASE
# ${configurationKey}.principalTransformation.prefix=
Enable and tweak the ones you want.
To understand what a configuration key is, see this.
Related
I'm attempting to setup a resource server that hosts resources that require different levels of security.
Through a web application I want to authenticate the users, by specifying the lowest Authentication Context Reference (e.g. basic email/password authentication). This provides an acr value for the session to the resource server. User can then access basic functions of the resource server.
If user wants to access resources of higher security, the resource server should redirect user to authorization server. This redirect should specify a higher ACR.
Within the authorization server, this new value ACR would trigger another authnetication flow including MFA.
The user would then reauthenticate with higher security and therefore obtain access to the requested resource on the resource server that required that higher security.
How can this scenario be achieved?
I do not see anywhere in Spring Security how to easily specify ACR values, or even to trigger re-authnetication of the user.
Checked many many website regarding step-up authentication, adaptive authentication, acr values, etc...
Here is my problem:
Context :
-Windows Server 2012 with ActiveDirectory
-Tomcat
-Rest API (Spring)
I'm currently trying to restrict REST request. I want that only specific groups of the AD could access to specific resources. I'm restricted to Kerberos authentication.
System configuration
Create a user in domain "Tomcat"
setspn -a HTTP/apirest.domain#DOMAIN
Generate a tomcat.keytab using ktpass
API rest configuration
I'm using the spring security sample on github that you can find here :
https://github.com/spring-projects/spring-security-kerberos/tree/master/spring-security-kerberos-samples/sec-server-win-auth
I know that there is an EntryPoint and this is not needed in my context (API Rest). I've chosen this sample because it seems to use the windows authentication context and use it to automatically authenticate me in the spring security context. Right after, an ldap request is send to extract all information about the user logged. In my case, I need to extract the group.
I'm also using :
https://github.com/GyllingSW/kerberos-demo
To extract the role of the user with the class "RoleStrippingLdapUserDetailsMapper.java" instead of the "ActiveDirectoryLdapAuthoritiesPopulator". This implementation also offers localhost authentication but the issue with the NTLM token seems to be fixed in last commit of spring security.
I'm not really sure if this is the right way to do what I want.
My authentication seems to fail and I only have one things going wrong in my logs..
"Property 'userDn' not set - anonymous context will be used for read-write operations"
Questions
Do I have to run my tomcat service using the tomcat account ? (Seems to be, yes)
Am I doing the right things with Kerberos security ?
How can I get rid of the anonymous context?
The anonymous context seems to be set just right after Tomcat start. I want to get a context just after that my user (For instance, user1) requests the rest API (EntryPoint or whatever)
If there is something unclear let me know, I will try to reformulate!
Thanks,
You do not need to query LDAP to get information about which groups does user belong to. Active Directory already adds this information to the Kerberos ticket which is sent from browser to Tomcat.
You just need to extract this information from the token for example using Kerb4J library. It comes with Spring integration inspired by spring-security-kerberos project so it should be pretty easy to switch to it.
If you still want to query LDAP you need to authenticate in LDAP before you can make any queries. Again there's no need to use end-user accounts for it - you can use the keytab file for Kerberos authentication in LDAP and query groups using "Tomcat" account
I found a way to fix my issue.
In a REST API context, you have no entry point. I tried to set my entry point to an unmapped URL, just to do the negociation. By doing this, you will receive an HTTP response with the error code 404 (Not found) but with the right header was added by spring security (WWW-Authenticate).
The web browser will not send the ticket service if the error code is not 401.
To solve this problem, you have to create a CustomEntryPoint class (implements AuthenticationEntryPoint) and you need to override the "commence" method to return a 401 HTTP code with the right header.
I hope that could help. If there is a better way, let me know !
After configuring two UAA instances as federated, say UAA1 (Relying party)--uses--> UAA2(ID provider) through OIDC mechanism, I can use UAA1 to authenticate users defined on UAA2 through authentication code work flow. UAA1 defines shadow users in its instance, but it does not capture groups defined for users on UAA2.
For example, user1_uaa2 is on UAA2 and it belongs to a groups called uaa.test. After login through UAA1, a shadow user user1_uaa2 is created in UAA1, but its group information is lost.
How can a user's group information be propagated back to relying party in OIDC based UAA federation?
Thanks
I think according to source code, that in last version of UAA (V4.10), UAA only returns openid as scope in id_token and /userinfo, no matter if the access token has roles scope or not. That means as either OIDC or SAML identity provider, it does not provide user group information.
It seems to me its codes work and are able to retrieve group information when UAA works as SP or proxy to other IDPs. It store those information to user_info table.
I have a setup with Tivoli Access Manager (TAM) as reverse proxy for some application servers on the backend side. TAM is responsible for authenticating users. Is it possible to access the credentials a user passed in during TAM authentication in the backend applications?
I need this because the backend applications connect to a Host-System and there the credentials are needed to log in.
there are a couple of options you might have for this :
Since you mention TAM, I guess you are still using 6.X, so you can use a custom CDAS (Cross-domain Authentication Service) library. You would need to implement the library yourself in C and handle the authentication part and return the clear text password as an extended entitlement in the credential. This will allow you to add this extended entitlement as an injected HTTP header for the junctions that require the password. You can get more information here : http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_web_devref58.htm%23chap-wsd-write-custom
You can implement your own External Authentication Interface. EAIs are external web applications where WebSEAL can delegate the authentication part. In that EAI, as in CDAS, you would have to handle the authentication part yourself - probably against TAM user registry - and then return the clear text password as an extended attribute in the credential to be used as a custom HTTP header for the junction that requires it. See http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_web_devref128.htm%23appx-wsd-eai
Leverage Tivoli Federated Identity Manager and a custom STS chain to do the authentication and return the clear text password as part of the credential.
For all 3 of the above options, you would need to modify the existing backend application to read the injected HTTP header and use the clear text password to perform the actions to the Host.
I have done all 3 for various integrations and I think your best choice is writing an EAI, as CDAS got deprecated with ISAM 7 and the 3rd option requires an additional software component.
I used Spring and Apache CXF to create a REST webservices application. I'm using x.509 certificates to authenticate the users, and then a custom authorization service to get all of the user groups and details. I've implemented a custom UserDetailsService that extracts the user information and populates a UserDetails object. Part of the process of populating this object involves a request to the corporate authorization service. The authorization service is unfortunately a proprietary system, but at least they provide a Java API. The authorization service, among other things, returns a list of groups that the user belongs to.
I'm still in the development stage, but my observations so far seem to indicate that the UserDetailsService is called once upon initial connection. Then each request uses a cached authorization object.
So my question and potential problem are this... Corporate policy states that applications are only allowed to cache the users authorization details for a set period of time. So, how long does Spring keep these UserDetails objects cached before refreshing them? And, how can I control this cache time to make sure I comply with policy?
There was a ticket submitted for something similar to this request:
https://jira.springsource.org/browse/SEC-898
The advice in the ticket is to create your own filter than periodically sets the Authentication.setAuthenticated property to false, forcing a look up of the user. You might be able to achieve the same by setting a smaller session timeout