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
Related
I 'm trying to create a secure spring rest api using pre-authentication security for siteminder.
I 've tried a solution where I 'm getting SM_USER and when I tested it in postman by adding new header SM_USER with random value it seems to work fine.
If you don't provide header I'm getting an error org.springframework.security.web.authentication.preauth.PreAuthenticatedCredentialsNotFoundException: SM_USER header not found in request which is valid.
But how can I be sure that this is secure? if someone knows the URL of my rest api could call this without problem. Should I check something else in spring or only siteminder offers user authentication?
The front-end SiteMinder web agent is the guaranty that the session is valid - you must make sure via server/network configuration that your application cannot be accessed directly without first passing through the SiteMinder web agent.
Also, SiteMinder asserts multiple headers. SM_USER should not be used alone because it can be asserted by the web agent in some circumstances when the user does not actually have a valid session. Instead, you should first look for the existence (non-blank) of SM_SERVERSESSIONID, which only exists if the session is valid.
Lastly, I generally try to avoid SM_USER at all - because SM_USER is actually not a user attribute at all, but rather is "the login identifier used for authentication". If SiteMinder authenticates users via federation (e.g. SAML) or x509 authentication, SM_USER will be rather different than if a login form was used. Instead, its better in SiteMinder to set a "universal id" that is a user attribute, and appears in the headers as SM_UNIVERSALID. Your SiteMinder administrators will know how to do this (and may already have - look to see if you have a SM_UNIVERSALID header available already).
One other caution, in some SiteMinder configurations, the underscore will not be in the header name (use of the underscore is called "legacy" header mode in SiteMinder), so you might want to make your app configurable with respect to the header names, e.g. SMSERVERSESSIONID, SMUSER, SMUNIVERSALID etc.
If you want to programmatically re-validate a session, you can use the SiteMinder Agent API or REST API, or look at my company's product "SSO/Rest" which provides a comprehensive set of uniform REST interfaces to SiteMinder and also other SSO providers (http://www.idfconnect.com).
HTH!
-Richard
I'm currently developing an app in asp.net core 2. However, i'm having issue configuring swagger properly and the authentication layer for the webapi.
In my instance, I have a web api that is configured with jwt. It uses the app id url as the jwt audience. Swagger is configured to run on top of this service and AAD is set up. However, because it's logging in to itself it has the resource configured as the web api client ID. Login successfully works, but the token does not work with the api calls. The main reason is that there is difference in resource/audience. The token is configured with an audience of the client ID and the webapi is conifgured with a jwtaudience of the app ID URL.
It only works if i configure the jwtAudience to the clientID. I doesn't work if i try to update the swagger resource as the app ID URL.
I need the jwtAudience to be configured to the APP ID URL. I can't figure how to do this thou.
Do i need to modify the AAD manifest to give permission to itself?
Any advice appreciated?
Thanks,
Derek
I have configured WSO2 Identity Server as IDP and have two applications configured as SP. All working fine, except few things:
when I logged out from one application, another application don't see, that I was logged out
when I login into one application, another application don't see, that I was logged in
IMHO, there is main principles of SSO and SLO.
When I check SecurityContextHolder.getContext().getAuthentication() there is no changes after logout or login in another app.
Maybe I should call WSO2 page /samlsso before every load url?
What can I do wrong? How to retrieve from another app, that user logged out/logged in?
EDIT:
For example, WSO2 API Manager Store have such mechanism:
when I logged out from my application and reload Store page, then going redirection to main not logged page in Store. Same with login.
UPDATE:
I found problem in class org.springframework.security.saml.websso.SingleLogoutProfileImpl. When logout request is coming from WSO2 IS, than objects Authentication and SAMLCredential are nulls and error No user is logged in is occured, but for real user still logged in in Spring SAML application.
Same discussion was here, but with no effect :\
You have to verify whether both apps are calling Identity Server (IS) using the same host name. E.g. https://is.blahblah.com/samlsso.
IS session is based on cookies ('commonAuthId' and 'samlssoTokenId' cookies to be specific). If apps are calling IS using two different host names, there will be two different sessions created at the IS side. For SSO and SLO to happen both apps must share a single IS session.
We are using travelocity.com and avis.com web app for test SAML2 sso. You can found the more details here[1]. Further you can checked this documentation[2] Registering the two service providers in the Identity Server and followed the 1 to 8 steps.
[1] https://docs.wso2.com/display/IS500/Configuring+Single+Sign-On+with+SAML+2.0
[2] https://docs.wso2.com/display/IS500/Customizing+Login+Pages
I have a requirement that needs to have login page at the service provider and I use java web app. Is there any way to use the spring SAML libraries to achieve this behaviour ? If so, what could be the steps? (it seems the default behavior of spring library is to redirect to IDP login page and I am not sure if we can configure to host login page on the service provider and relay that request to IDP)
I think what you're looking for is having two different ways to authenticate, one locally and one through SAML. I believe for having a login form, you would want to separate configurations with different AuthenticationEntryPoints, i.e. go to /login for local or /saml/login/alias/" + spAlias+ "?idp=" + spEntityID for direct login to SAML.
It sounds like right now you have SAML protecting any URL, which by default redirects you to the IDP since it's configured. The first step that I would take is getting user name and password authentication working with logins independently of SAML, then add SAML back in. Be sure to list whatever URL the login form uses as permit all so SAML doesn't kick in.
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.