I have a requirement of connecting single service provider to connect set of multiple Idps in shibboleth SSO. After googling i get to know it can be achieved Using Embedded disovery service.After installation and configurations i'm getting redirected to idp select page, but there are no idps in the list.when i checked the idpselect_config file, there is a datasource ="/Shibboleth.sso/DiscoFeed". Discoveryfeed file which is json formatted containg idp's metadata. I tried by converting idp metadata xml file to json formated file and copied to the same folder to shibboleth-ds(where embedded dscovery files located). Still no use. No Idps are in the Idp select dropdown.
Can any one tell me how to do this or do we get any sample discovery feed file
Thanks in advance
/Shibboleth.sso/DiscoFeed is a handler provided by Shibboleth SP. That handler will return a JSON formatted list of all of the IdPs that your SP is integrated with, by consuming the metadata of the IdP.
Have you configured your SP with <MetadataProvider> elements for each IdP's XML metadata?
Basically, the Embedded Discovery Service works in conjunction with the handler from Shib SP to provide the drop-down.
What is returned when you browse to https://{your-server}/Shibboleth.sso/DiscoFeed?
Related
I am working on SAML for the first time,
I have my IDP Metadata file,
I am on SP to connect the IDP.
I did not know what to do, so I read an article on Google which led me to believe that I required an "authnrequest" which goes to my IDP from my SP.
I have used the "codegreencreative/laravel-samlidp" package.
So how can I generate an "authnrequest" for my SP?
I have generated "Self-Signed Certs" also.
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 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.
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 am using Spring Security SAML to have my application act as an SP. I was able to have the end-to-end solution done. However, I am facing a problem when the user wants to access the application using more than one URL. I have configured my SP metadata with the Assertion Consumer Service URL to be mywebsite:8080/myapp/saml/SSO.
The user can also access the application through the full domain name
mywebsite.fulldomainname:8080/myapp/
If the user accesses the second URL, The SP application will redirect to the IDP which will return the first URL which will fail giving this message:
InResponseToField of the Response doesn't correspond to sent message
Even if I used the EmptyStorageFactory, it will still fail in the AbstractProfileBase.verifyEndpoint
How can I fix that?
Part of the SAML's security model is verification of the intended endpoint - where IDP wants to deliver a SAML message - and endpoint where SP actually received the message - the two need to match. Therefore your SP metadata needs to include correct information about the URL where it expects SAML messages to be delivered. You will encounter errors in the verifyEndpoint in case the SP metadata has different URL than where your IDP delivers the message.
Spring SAML allows you to define multiple different metadata (with different URLs) for the same deployment. So you can solve your problem by generating one metadata for mywebsite:8080/myapp, the other for mywebsite.fulldomainname:8080/myapp/ and importing both to your configuration. Each of those will have to have a different entityId and will also need to be separately imported to your IDP.
You can find more details in chapter 7.2 of the Spring SAML manual - pre-configured metadata.