I have searched only for many hours trying to find an answer but cannot. I have an up to date version of Shibboleth working in my RedHat el6.x86_64 proxy server. (SELinux is in permissive mode.) I have a Service Provider setup.
It works well with a particular default IdP. However, when I add the Embedded Discovery Service so that users can select one of two IdP's then there is a problem I cannot get passed:
The user types the resource and gets redirected to the discovery page. They select the IdP they want. They log into that IdP without a problem. After submitting their authentication to the IdP, the user gets redirected to the correct resource but THEN ALWAYS GETS IMMEDIATELY redirected back to the discovery page. In the Apache logs I see that the authentication credentials from the IdP were good.
I've looked extremely closely at the Apache configuration and do not have the redirect in there. All I have is this below for my resource as well as the default /etc/httpd/conf.d/shibboleth-ds.conf and /etc/httpd/conf.d/shib.conf files.
Order allow,deny
Allow from all
AuthType Shibboleth
require valid-user
ShibUseHeaders On
Require shibboleth
In my shibboleth2.xml file I definitely did exactly as the Shibboleth Embedded Discovery Service instructions say. Every tag is in place. I also tried different parameters within the shibboleth-ds/idpselect_config.js but that didn't help. Can someone please give me some guidance? Thank you.
The checkIP and consistentIP settings needed to be adjusted.
Related
We are using Okta Customer Identity with our application. The challenge with our architecture is that each user gets their own server and subdomain, which is a little weird for Okta, because each redirect URL needs to be provided as part of the application configuration. As we add new users, the list of redirect URLs continues to grow, one per user machine. Their API is not really designed for this, so we have to write the complete list of redirect URLs with every change.
We would like to find a way to use a proxy for the Okta authentication, so that we can just have a single redirect URL for the Okta application configuration. But we're using https://github.com/okta/okta-spring-boot, and we're not really sure how to make it work with a proxy.
If we set up an HTTP proxy using -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=8080, that's going to affect all HTTP traffic, which is not acceptable.
Is there a way we can use an HTTP proxy purely for the Okta auth only, leaving all other HTTP traffic unproxied?
Is there something we can do with the Okta Spring Boot library that would make it possible for all user machines to share a common proxy machine?
The final alternative would be to write some "active" proxy code that runs on the proxy which handles the requests and forwards them on to Okta. It would have to introspect the Okta response and pass it back to the right user machine.
Is there a way to do #1?
Failing that, is there a way to do #2?
If neither of those are possible, are you aware of an existing implementation of #3?
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 !
I am using Aacotroneo/Laravel-Saml2 and have successfully setup a login system using ADFS. In another system I am using simpleSAMLphp elsewhere on the same domain successfully with WIA so I know ADFS is setup for that and that everything is setup correctly except the laravel application.
I have installed a browser addon to check the SAML logs for responses and requests. The only thing I can think of is that there is no client request ID sent through from laravel.
&client-request-id=d1ccbbdd-d55e-4828-eb24-0080000000b4
Any suggestions are appreciated. If I have missed a saml2 setting I am more than happy to try them, a lot of them don't seem to work or make any difference whether set to true or false.
Is it possible I need to setup encryption certificates and certain true/false combinations?
Thanks
Check this article
ADFS has non-standard SAML2 Authentication Context Class urn:federation:authentication:windows
By default this class has lower priority than urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
I would suggest making the following changes to AuthNRequest:
<samlp:RequestedAuthnContext Comparison=”minimum”
<samlp:AuthnContextClassRef xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">
urn:federation:authentication:windows
</samlp:AuthnContextClassRef>
<samlp:AuthnContextClassRef xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</samlp:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
I am doing a POC where I need to integrate the Shibboleth SP with OKTA idp provider.I have completed all below steps documented on OKTA official site for this integration.
Install Shibboleth Service Provider
2.Configure the webserver to use Shibboleth
3.Configure Shibboleth to protect a specific folder Create an Okta SAML 2.0 Template application
4.Modify Shibboleth to use the metadata obtained from the Okta application 5.Modify the attribute-map.xml file within Shibboleth
to set the appropriate header variables
6.Restart everything
But there are details missing from the step 5 where I need to modify the atrribute-map.xml. when I fire my protected URI(hosted on apache) it is getting redirected to OKTA login page. But after user enters the user-id and password and clicks login I get a spinner on my browser and it never takes me to my protected site URI hosted on Apache. Any clues to fix this attribute-mapping in Shibboleth SP is highly appreciated.
If the page is not being redirected to SP, he problem need not be with attributes-map.xml
Endpoints could be incorrectly configured. Check
{web app uri}/Shibboleth.sso/Metadata to see if the endpoint URLs are correctly defined.
Check Shibboleth2.xml if entityID is correctly defined, this is the web application that Shibboleth is protecting.
Check {web app uri}/Shibboleth.sso/Session this displays if all the attributes that are being sent from Okta. You can make it display the values too by changing Shibboleth2.xml since it is just POC.
Finally comes attributes-map.xml where you can configure attributes as agreed with Okta. There are some default attributes like NameID that are pre-configured here. You can see the format in attribute-map.xml and in /Shibboleth.sso/Session and code to make use accordingly. For example
formatter="$NameQualifier!$SPNameQualifier!$Name"
If you are adding custom attributes a simple element as shown below should work as long as the name is matching the attribute name that Okta is sending.
This issue was resolved by doing proper configuration on the OKTA side .OKTA provides sam2.0 template app for integration with shibboleth .The below mentioned parameters of this template app were properly configured.
Post Back URL -
Name ID Format - Transient
Recipient -
Audience Restriction -
authnContextClassRef - PasswordProtectedTransport
Response - Signed
Assertion - Signed
Request - Compressed
Destination -
Attribute Statements - username|${user.userName}
Then our integration was succesful
I have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.