I have configured IdP and SP in my desktop.To test SSO, I have a single html page deployed in tomcat.I have given the url : http://machinename:portno(here tomcat's port)/webApp/index.html in default url of SP configuration. When I try to hit the SP SSO url,(http://machine_name:portno/sp/startSSO/ping) it redirects to IDP and prompts for authentication. Once the user is authenticated, the user is redirected to the tomcat webpage.
But, when I try to access the tomcat page, I am able to access it without any authentication. Is there any configuration on the SP side? If so, how to do it? When I access the web page, I should be prompted for authentication.
This configuration question really has nothing to do with PingFederate. This is more about how you have chosen to integrate your Tomcat application with the PingFederate SP Adapter. Chances are you are using the SP OpenToken or SP ReferenceID Adapter for a Java app in Tomcat- these Adapters merely provide the user's identity attributes to your application after the SAML Response is validated by PingFederate SP. It is up to your application to validate the specific token type (using the proper steps required by the SP Adapter you have chosen) and then your application is also responsible for enforcing access/maintaining a session based upon the user's identity that is passed in the token.
If you are expecting Access Control/Session management, I'd recommend looking at integrating PingFederate with PingAccess.
Bottom Line: Ping's solution's are hugely flexible so there are a number of ways to accomplish this based upon your application infrastructure and use case requirements. I suggest that you work with your Ping Identity RSA to help you work through these questions in order to have the best possible outcome.
Related
I have multiple web applications running in different domains. Okta is the identity/auth provider for all these applications. After integrating with Okta in one of the application (following the Java example provided in Okta documentation), a new cookie (sid) is being created in Okta domain (https://developer.okta.com/docs/reference/api/sessions/).
How do I use this to SSO into other web application. What is the best approach to allow access to other application without prompting login credentials again?
Do I need to invoke getCurrentSession API in every application and redirect to login page only if the API response is 404 (as per doc, getCurrentSession will retrieve the current active session based on the Okta cookie).
Please share thoughts.
It all depends on how you integrate your apps: redirect to Okta or using Okta widget. If you do redirect it's pretty much guaranteed to have zero issues authenticating in your second app, as your redirect for second app will send sid cookie back to Okta, which was set while authenticating with your first app.
With widget things may become bit complicated, as it depends on 3rd party cookies. okta-auth-js GitHub repo has some examples on how you can check if session exists with okta, when you trying to authenticate a user. Check https://github.com/okta/okta-auth-js#third-party-cookies
I have an existing application and all of a sudden i have been given a task to implement IDP initiated SSO. there is a URL to IDP clicking on it asks me to login with IDP provided credentials, after success login the route moves to our application and than my task start to identify the user and give the proper access. I have the certificate provided from our IDP. How can i achieve this? My application is a Spring MVC Java Application.I am using JBOSS AS 7. I havent done a similar thing before. Can anyone please give a step by step clear picture on this? I saw the Spring SAML extension which i couldnt understand properly to get it integrate with my existing app. Any help in this regard will be highly appreciated.
IdP-Initiated SSO
IdP-Initiated SSO with POST Binding
If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML message. The message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
See saml-tech-overview-2.0
So if you are implementing the SP, you have to follow the steps 5 and 6 otherwise 1 - 4.
For the implementation you could use OpenSaml if you do not get it working with the Spring SAML extension.
I have integrated Spring Saml with my application and it's working fine. I am able to login using SP-initiated SSO and IDP-initiated SSO. Also I added local logout settings as well. But I got one more requirement where user will login using SP-initiated SSO. After successful authentication, user will go to IDP selection page (ADFS 2.0 in my case) and select one SP and click on logout from this site.
At that time I need to trigger a session termination for client browser where my SP home page is open. Other SP should not be affected for this user.
There are many question related to single logout but my scenario is bit different. I want to logout from my application from global IDP page. Though I am able to logout locally and session is getting terminated. I have configured all setting given in this Spring-Saml doc.
Yes, there is a lot of doubt about SingleSignOut. But I believe that what you want is not the standard Single Logout Profile (paragraph 4.4). And ADFS certainly will not initiate the signout through the backchannel (SOAP Binding for paragraph 4.4.3.3.).
Maybe you can do the "illegal?" LogoutRequest (because all SPs should be singned out) with Redirect or Post binding from the IdP (ADFS). But maybe (I doubt and did not verify on the current patch levels) only in ADFS 2.0 on S2008R2 and S2012. On S2012R2 there is no chance at all. It is a dead-end street.
I guess Signout from one app really has no meaning. It is SSO! You could clear the local SP login session cookies and try using ForceAuthn on the AuthnRequest from the SP to the IdP. Would that produce the required effect? At least that is standard.
I have a web application which requires username and password authentication to enter.
What I am doing is, authenticate a user from a stand alone Java app, which would do so by making Http request to the server using username and password. Then I would retrieve JSESSIONID cookie from response of server.
Now what I want is to use this JSESSIONID to continue session on browser i.e. to let user navigate pages of my web app which would be opened by my stand alone java app which I use for authentication.
Is this possible? Or is there any other way to do so.
Cookie can be changed using below mentioned methods.
Cookie cookie = new Cookie("JSESSIONID", NEWSESSIONID);
response.addCookie(cookie);
From your application you can send JSESSIONID as parameter while opening browser first time and reset your cookie using above method either in filter or servlet. This will reset your cookie in client side once you send response back. Next request on wards you will be able to access the session created previously.
It's possible but it's not that simple.
Since web applications don't share sessions, what you're looking for is a Single Sign On (SSO) solution, which involves an "Identity Provider" (IdM) that authenticates users for one or more "Service Providers" (SP). In this case, your servlet is the IdM and your web app is an SP.
Depending on your deployment, the following are third-party, open-source SSO libraries that you may be able to use:
Kerberos
PicketLink (for JBOSS)
OpenAM (for Tomcat)
If you don't want to use a third-party library, you may also be able to modify your servlet to be the IdM. Either way, I suggest reading a little about Security Assertion Markup Language (SAML) before deciding on a solution. SAML is a popular method that the above libraries implement.
I have 4 single page applications with same technologies: Spring MVC, Spring Security, Angulajs.
Each application has own ldap authentication and authorization. We want to build a single sign architecture and make a central authentication application. And make the other 4 application use this central application.
When user login into one of the apps, he should not need to login the others.
What is the easy way to implent this in server side and client side?
What you want is Single Sign-On (SSO). There are two options:
Use some existed SSO server like CAS.
Do it yourself using subdomain cookie technique.
First option is exactly what you want implement. When you open URL of app1 you will be redirected to SSO server and prompted for login/password. After successful authentication you will be redirected to app1 URL. Now if you open app2 URL you will be signed in automatically. One of advantages is that user password is stored only in SSO server.
Second option is more lightweight IMHO, because instead of using existed SSO server for sharing authentication information between your apps you use HTTP cookies. From the other side you need to write some minimal authentication code which may be less secure.
Subdomain cookie technique:
Use subdomains for all your apps (app1.domain.com, app2.domain.com)
When user connects to app1, generate some token (your session id), store it in some shared DB and as a cookie for domain.com
When user opens app2, check if token is present (as a cookie for domain.com), verify that it is valid (use shared DB) and allow access.
It is very simple algorithm that do not take into account all possible security vulnerabilities (like session fixation for example). So if you do not have enough time to solve them it may be better to go with first option.