I am trying to implement SAML SSO between two J2ee applications (form-based) deployed on two different instances of WAS, I have configured both WAS instances as service providers using the steps in http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftwbs_enablesamlsso.html
I set the property sso_1.sp.login.error.page to the login page of the Identity provider but when I get redirected to the login page, it displays that no SAML request (AuthRequest) is available, can anyone tell me why the WAS is not issuing the SAML authentication request?
WAS does not send a SAML request in the redirect. This is explained in the paragraph above this section of the DeveloperWorks SAML TAI article. The scenario you're expecting is referred to as the solicited response. WAS only supports what the article terms the unsolicited response. In this latter case, the IDP must understand how to authenticate the user (usually through a browser interaction) without a SAML request.
Related
I am trying to integrate OKTA as service provider to provide access to the custom application for external customers.
External Users login to enterprise Idp to access the custom application
After successful authentication IDP triggers the IDP-Initiated flow and submits the SAML response to OKTA
OKTA checks for the external user information in the SAML assertion and sends these details to Custom API application to identify the user
If the user is found, the API returns the required information to OKTA
OKTA will initiate the PKCE flow to provide access to the custom application
I was success in configuring the OKTA and external customer IDP. But, Can anyone knows how OKTA will call the custom API application to identify the user information? Also, how to configure the redirect URL?
unfortunately I don't have an answer to your question as we use PingFederate but I was curious as to how you setup Okta (as the SP) to accommodate the IdP-Initiated call, without having to call back into the IdP for authentication? I ask because, as the IdP, we are calling Okta (as the SP) and the SAML response but the vendor is stating they cannot setup Okta without the IdP URL to call back into to have us, the IdP, authenticate the user. Seems your setup works how we believe it should so wanted to get more details about this.
I need to implement SAML SSO in a webb site based on web forms, can someone please show a example of how to that?
You need a SAML stack on your client.
Some of the commercial clients have examples of this.
Basically:
Configure the client-side SAML parameters based on your IDP
Have a form with a Login button
When the button is clicked, use the stack to send an AuthnRequest
This will trigger an IDP login form
After the user has logged in, the IDP will return to your Assertion Consumer Endpoint with the SAML token
Use the stack to extract the attributes you need
I have a portal application developed using spring security and mvc framework. This portal application connects to IDP (Developed using Spring security and spring saml) for authentication. if the user authentication is success,user will be navigated to homepage where multiple links are provided for external applications… When the user clicks on the application link, user should successfully navigated to the respective application without challenging login page.
Other applications are developed using struts and spring security. How do I make sure that when a link is clicked from the portal, either saml token or context is passed to other application so it will not ask for login.
Any help is greatly appreciated.
The most common flow for SAML is something like the following:
Application (called service provider, or SP) receives request (any request, like request for a business resource) from unauthenticated user
It redirects the user (most commonly via http redirect) to the IdP (in which the SP should already be registered)
If the user is not authenticated to the IdP (not logged in to SSO), a login form is presented and login is managed by the IdP until there is a user session with the IdP
If the user is already authenticated with the IdP (because either he was already or entered a correct user/password), the IdP issues its claim token and posts the user with the token back to the Assertion Consumer Service in the SP (the original application)
The Assertion Consumer Service (practically just an API endpoint) receives and validates the SAML token and creates an own application session with the user. Now the user is authenticated to the application (SP)
Upon the next request to the application (SP), there is already a session, so SAML is not involved
Note that if there is already a session with the IdP, all of this is seamless for the user. A bunch of redirects take place, but the user will just reach the application without entering credentials.
So the short answer to your question is that your external applications need to support SAML SSO and need to be registered with the identity provider, in which case they can just use the IdP for authenticating the user and signing the claims it may have.
Currently, I'm using spring-security-saml2-sample project(V1.0.1) as an SP, and Shibboleth as an IdP. I've implemented the Web SSO profile and trying to write an ECP client to make ECP profile work. However, I found limited documents about ECP profile in spring security saml(Ref doc Chapter 10.4)..
I found two useful ECP client samples in github:
github.com/spaetow/ShibbolethECPAuthClient
github.com/DARIAH-DE/shib-http-client
After enabling PAOS binding and "ecpEnabled" in SP's metadata generator, I wrote some sample ECP client code refering to the above two project, the main flow is:
Send a Get request to "localhost:8080/spring-security-saml2-sample/saml/login" with PAOS related header.
Get the response(SAML Request) and generate a SAML Envelope.
Use the new generated SAML Envelope to Post to Shibboleth IdP(https://exampleIDP/idp/profile/SAML2/SOAP/ECP), with UserName/Password in Authorization Header(basic authentication).
Shibboleth authenticate and response with SAML Assertion(Also an SAML Envelope).
Send the SAML Assertion(Envelope) to SP: "localhost:8080/spring-security-saml2-sample/saml/SSO" and get response.
I think I've succeeded in the first four steps, Shibboleth can authenticate the user and send the SAML Response. But I've got some problems in the 5th step. And even some examples end in step 4.
I found that, spring security saml gets the 5th request and tries to Authenticate the SAML response just like WebSSO profile does. The logic is in "org.springframework.security.saml.SAMLProcessingFilter". After parse the saml response and get the Authentication, the response will be redirect to a default target URL"/". The logic is in AbstractAuthenticationTargetUrlRequestHandler.handle(req,resp,authn). So, I can only get an 302 HTTP response in the ECP client.
Here are my questions:
I want to get user information in the 5th step, do I have to write another filter instead of "SAMLProcessingFilter" to send the Authentication as response? Or is there any other ways(I think ECP client cannot parse SAML Assertion received in Step 4)?
In this situation, my ECP client likes "Rest client" very much, because I have not record any cookies in my code. So after the 5th step(after login), how can I access the SP again for another resource? Does that mean I have to record the JSessionID cookie in the ECP client?
Is the theory of SAML SSO(WebSSO) like Jasig CAS(Use cookie/session)? If so, in the ECP mode, How can I single sign on two ECP clients(each connect to different SP but SP cpnnect to the same IdP). Or, can I make SSO in a ECP client and a browser?
Thanks in advance!
I had a requirement to implement spring security saml implementation.
And I want to connect to IDP(Identity Provider) to authenticate without using IDp's login page. In my case, I want to use Service Provider (login page)..
Is this possible? If yes how to achieve this?
You can try with WSO2IS with request path authenticators which validates user credentials comes from SP login request. If you take SAML2 SSO scenario, SP can send SAML2 Auth request using POST binding to IDP. In the same request SP can send the end user's credentials that is retrieved from the login page of SP application. Then you would not see the login page in IDP and credential are retrieved from auth request and validates with IDP's user store. If success SAML2 response is generated. You can take help from this link.
This is not really a good idea since by definition, the service provider is not supposed to authenticate users, that is the IDP's responsibility.
If you are concerned about branding.. you may be able to request the IDP to personalise their login page if your SP has requested authentication although it is slightly unlikely that they will agree to this.