how to achieve global Logout for specific SP from IDP side? - java

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.

Related

Single Sign On with Okta session

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

How to use tomcat authentication whenever a page reloads

I have been developing a web app consisting of a login page and users database maintenance and i am using tomcat authentication to verify users credentials. I have configured the tomcat in such a way that when the url of certain servlet is called the authentication pops up. But i can use that authentication only once and after logging in if i come back to the same page there is no authentication from the server.
Yeah i found the answer. Just include the Session.Invalidate() code in your corresponding sign out page and it terminates the session. But you have to change the authentication from to FORM.

Angular: Detect Logout after Server Restart

I created an angular application that exposes a RESTful API and uses spring security (with LDAP) by using this post as reference and I managed to get it to work. The only problem is that if the server application (where the spring security is configured) is restarted all users are logged-out, but if the user leaves their browser page open they can navigate through the screens without a problem until they do something that would require access to the server.
So my question is: is there a way to automatically log-out the user or re-authenticate them when a server restart is detected (and how would one go about detecting such an event)?
to re-authenticate the user
you need stateless/sessionless API, consider using token based authentication, spring security OAuth has this. If you really need session, save it on the database not on your application server, spring session has this.
to automatically log-out
the easy way is that if you angular try to access the server and it receive 401 forbidden from the server, then redirect the user to login page or popup window login. The user is automatically logout when the server is restarted, is just the client/angular doesn't aware of it.
I managed to tackle this issue by implementing an interceptor as described in this post. I also implemented an $interval to detect that the user is unauthorised as soon as possible.

Integrating a single page application with Ping Federate

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.

Redirect using SAML is not landing in my configured page

I am facing an issue while using SAML to implement SSO on my web application.
After successful login I want to redirect to my application’s dashboard / main menu. But, it gets redirected to http://:/IDBUS/first-idau/IDP-1/SAML2/SSO/POST.
The flow is, I request my application’s context url in browser. In josso I have configured it to be redirected to atricore. Then there is a change in request headers and the request comes back to same application url I requested. Now I use a filter and redirect it to JOSSO login page. So this single request lands in JOSSO login page.
When I give credentials and login, then JOSSO authenticates and sets the user principal and sends the request to my url. Here I have a filter to forward to my dashboard.
In this step after I give authentication information in JOSSO login page, instead of getting my dashboard, it gets redirected to some JOSS page (http://:/IDBUS/first-idau/IDP-1/SAML2/SSO/POST) this is in OSGi bundle in Atricore.
When I debug, I see a HTTP header as “referer”. It pointing to the above URL. I think it should point to my application’s dashboard url which I have configured in josso-agent-config.xml
I did one analysis and found something interesting. In step 1, I have used a filter in my application to redirect to JOSSO login page. Instead of doing that, I allowed to complete the request. Then it gets landed in a page in my application.
Now in the same session (in browser), I manually made request to JOSSO login page. Then I got the JOSSO login page (this is step 2). Then I gave credentials and requested to login. Now it gets successfully forwarded to the intended my application’s dashboard page.
So my guess is that, there should be something wrong with my filter where I redirect to JOSSO login page.
I am using Atricore Identity Bus 1.0.0-m1+JOSSO 1.8.2+Spring 2.5.6.SEC01. Please help me on this.
First of all, I'd strongly suggest you to upgrade to Atricore M2 which was released last week and available here : http://sourceforge.net/projects/atricore/files/Atricore%20Identity%20Bus/Atricore%20Identity%20Bus%201.0.0%20M2/atricore-idbus-1.0.0-m2.zip/download . This release delivers tons of fixes and many significant enhancements such as native HA and scalability out-of-the-box support.
Also, make sure that you're using the final JOSSO 1.8.2 bits - not JOSSO 1.8.2 r1575 - released last week and available from the JOSSO web site (http://www.josso.org) .
Then, you should deploy the reference identity appliance for realizing a simple SAML-based Federated SSO setting encompassing a JOSSO Service Provider and a SAML2 Identity Provider. Make sure to follow the quick start :http://www.josso.org/confluence/display/IDBUS/Quick+Start
Going back to your original question, the URI your seeing is because JOSSO is relying on a SAML2 IdP Entity the authentication request (read: AuthNRequest) which, upon handled, returns the correpsonding SAML Response conveying authentication assertions.
The bottom line is that within a FSSO setting, the JOSSO Gateway concern is realized by an Identity Provider hosted in Atricore IDBus. Atricore Identity Bus is playing nice with JOSSO Agents (read: by speaking the "JOSSO" protocol) while bringing the standard-based FSSO capabilities on board, and without forcing you to invest in retrofitting your JOSSO Partner applications to SAML.
Hope this sheds some light on your issue and the subject in general.
Regards,
Gianluca.

Categories

Resources