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
Related
currently, I'm working on an application in which we want to offer a single sign-on experience, but let me put you in the context:
We have two different Cognito clients created for the same Cognito pool, both are configured to allow the users to login into two different applications:
App A: mydomain.com
App B: appb.mydomain.com
well, the thing is that when a user uses the hosted UI to log in to the first application, I noticed that the Cognito server creates a cookie called "Cognito" as can see in the image:
Cookie set by the auth server
Then, when a user tries to access the other application appb.mydomain.com, and the application, instead of showing the hosted UI, the user automatically enters the application without going to all the login process again, and this is possible because of the cookie I mentioned (when I delete that cookie, then the user is requested to login again using its credentials).
So, that's nice because the user doesn't need to go through all the login process again. But my situation is the following:
I want to create a login page in mydomain.com with my own customized form and using the Cognito SDK. I already have the backend working, also the frontend. The backend can authenticate users to get the JWT tokens (IDtoken, refresh token, etc.) as you can see in the next image:
Tokens I get when I authenticate a user
But at this point I'm not able to redirect the user to appb.mydomain.com with a valid session, I mean, I have the JWT tokens, and I tried to do the same thing that the hosted UI clients are doing, that is setting a cookie somehow containing the JWT session. But I don't know how to make the application appb.mydomain.com to be able to detect this cookie. But the most important problem is that I really don't know how to construct a valid cookie (like Cognito's) to be detected by mydomain.auth.eu-west-1.amazoncognito.com (this domain is shared for both Hosted UI clients).
I don't know if this approach is feasible, or if there is another approach to send a JWT token to the auth server with a callback to redirect the user to the appb.mydomain.com
without going to all the login process again or something like that.
Do you have any advice on how to implement this kind of SSO Experience? I'm using .Net Core in the backend.
I was creating my own oauth2 server with SSO enabled for Google and Facebook. I found this example https://github.com/spring-guides/tut-spring-boot-oauth2 to be very useful and I was able to make my oauth2 server expandable after several tweaks.
For session storage, I used redis and everything seems to be working with the spring magics.
However I encountered a session problem when implementing logout. According to single sign on best practice, when a user logout from one client, all other clients with the same session from the auth server should also be logged out. So I added an endpoint for each client to invoke upon successful login to register it's name based on the user session from the auth server. However I noticed that each time I refresh the page on my client web app, I get a new session from the auth server. As a result, each time when I try to logout, the session associated with all registered clients will always become the old one.
I've been searching for solutions online but no luck yet. It would be greatly appreciated if someone could help me with this issue.
TL;DR version:
I implemented an oauth2 server with SSO enabled for Facebook with Spring Boot. After I successfully logged in with my Facebook account, I can see my client web app resources. Every time I refresh the page, I see a new session gets created from the oauth2 server and it gets stored in the redis storage and all the old sessions are kept in the storage as well.
UPDATE
It seems that all the new sessions are generated by anonymous users each time I refresh the page.
Ok after some digging, it turns out that anonymous user by Spring Boot is not much different from unauthenticated users, according to this doc https://docs.spring.io/spring-security/site/docs/current/reference/html/anonymous.html.
It makes sense that every time I refresh page a new session would generate. My problem was that I wasn't using the correct session ID when registering client app upon successful user authentication. Therefore I override "SavedRequestAwareAuthenticationSuccessHandler.java" file so that I can obtain client_id from the request parameter and then register the correct session ID obtained from the Authentication object to this client ID.
I'm doing some research about authentication via Active Directory for internal application.
Application is divided in two parts - front-end in Angular 2, and back-end in Spring. I would like to add windows authentication to it to avoid providing credentials when you are already logged in, but i can't fully understand how possibly server knows the credentials of which user to compare with those stored in Active Directory. For example let's assume that I've logged into windows, my data are sent to Active Directory. Now I'm heading to website, which i would like to automatically authenticate me with http request sent to rest api. Rest server invokes some logic connected with authentication with Active Directory, and after success rest api sends token back to Angular. But the thing I'm missing is how server knows which credentials compare to know if user exists in AD. Should i somehow use angular to gain acces of user credentials stored in windows through browser? Or I'm missing something important here.
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 have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.