I have successfully set up my own application with Google SAML, but now I can't understand how do I implement SSO with Google as my IdP.
For example, according to the SAML standart, I (the service provider) should be able to send to Google IdP a logout request to logout a certain user from my system, but I can't find any info about this in google docs.
Similar thing about implementing true SSO in case I will have multiple web services, and I would want to make SSO between them - I can't find any info about that on Google SAML. After Google sends me SAML assertion with user email, that's it, I can't interact with Google, I can't create SSO between my multiple web servers.
So, does Google SAML support SSO? Because it seems to me that the only thing it does is send SAML assertion to my callback URL and that's it.
For example, according to the SAML standart, I (the service provider) should be able to send to Google IdP a logout request to logout a certain user from my system, but I can't find any info about this in google docs.
Google doesn't support SLO, the problem is that this fact is not officially documented, the information can only be found by third parties
Regarding to this question:
I have successfully set up my own application with Google SAML, but now I can't understand how do I implement SSO with Google as my IdP.
I'm not sure if I'm grasping the situation correctly, but I understand that you need your users created on Google to access other configured apps through SSO. In theory (based on my understanding of your question), this federation should be configured within the Admin console as a 'custom app' just like you did it following these steps
Could you elaborate a bit more about what's the behavior you are expecting?
References
Keeper's documentation SAML setup with Google as IdP
Related
I've got IdentityServer4 running with Google as a 3rd party identity provider. When a user logs in to IdentityServer via Google, how can I make IdentityServer detect, or otherwise get alerted, when the user logs out of Google directly? To be clear, I'm not trying to log the user out of Google when they log out of IdentityServer.
According to the IdentityServer4 docs:
"Federated sign-out is the situation where a user has used an external
identity provider to log into IdentityServer, and then the user logs
out of that external identity provider via a workflow unknown to
IdentityServer... Not all external identity providers support federated
sign-out, but those that do will provide a mechanism to notify clients
that the user has signed out".
Does Google support this? I'm guessing, though not sure, that this functionality goes through the "check_session_iframe" OIDC endpoint, which I don't see in Google's discovery document (https://accounts.google.com/.well-known/openid-configuration).
If Google does support this, how do I configure in IdentityServer, or via the client app (using oidc-client-js) to get this notification? Currently I'm handling the oidc-client-js UserMangager event for addUserSignedOut() where I'd expect this to go. Indeed, when I externally sign out of IdentityServer directly, this gets called.
Google and Facebook external identity providers does not support federated sign-out.
For more details refer to this link - Identity Server 4 - federated logout of google when used as an idp
However those identity providers who supports federated sign-out, for OpenIdConnect, you can use OpenIdConnectEvents in services.AddAuthentication().AddOpenIdConnect(...) method in Startup.cs to check remote sign out event.
We have a Web App using REST API. The REST API is based on Loopback and uses it's built-in token-based authentication. For the Web App we use forms based authentication over HTTPS, so the user has to enter his username and password which we then use to get access token from the REST API via POST /users/login endpoint.
One of our customers asked us to support single sign-on (SSO) authentication through SAML 2.0 and AD FS.
We configured our Web App as a service provider (Relying Party in AD FS) and managed to support SSO for it. The changeling part is the authentication between Web App and the REST API. The idea right now is to configure both Web App and the REST API as the same Relying Party and add new POST /users/saml-login endpoint to the REST API, so the Web App can send a SAML response to that end point and get an access token based on the claims specified in the SAML response. Everything else should work as it used to work before. Here is the flow I imagine:
Web App generates SAML request and redirects a user to the IdP login page
After a successful login the user is redirected back to the Web App with the SAML Response
Web App acts as a proxy and redirects the SAML Response to the REST API endpoint (POST /users/saml-login) where it is validated
If the SAML response is valid the API returns an access token based on the claims
Web App uses access token for further communication with the REST API same as before
Here is the question: Is it OK to implement SAML-based SSO this way? Do you see any issues or security considerations with this approach? Are there any alternatives?
I have read a lot of articles on the web and questions here on StackOverflow about how to use SAML & REST API together:
Propagate SAML Assertion Response/Security Context to downstream Services/Apps
REST API authentication with SAML
SAML and back-end REST service authentication
Attacking SSO: Common SAML Vulnerabilities and Ways to Find Them
None of them really helped me to confirm or reject the idea described above.
That sounds like a reasonable approach. I can't think of any security issues.
You're simply re-posting the SAML response internally within your application for processing. As long as you then perform the various security checks on the SAML response and assertion within your REST API, there shouldn't be any issues.
Our company maintains a Web App composed of a front-end and a back-end in (Node.js), and we support the standard username/password login authentication. A couple of our partners have requested we support SAML SSO, so their end-users can access our web app through a link on their respective portals without the need to login again.
Question: Do we need to turn our app into a full-fledged service provider (SP) by implementing a SAML sdk/library in our front-end and back-end?
Or is it possible to use a 3rd party authentication provider like Okta to handle the SAML nitty-gritty behind the scenes and then redirect the end user to our app, with possibly a token (JWT?) so we can retrieve the user info from Okta?
I've read everything I could find on Okta's site, and here, and couldn't find a definitive answer, either yes it's possible (with example) or no you can't do that.
Like you already mentioned in your question, there are 2 possible ways to do it.
Update your application to support SAML login flow with your app as SP, in which case you will not need to use any 3rd party auth provider
If you don't want to get into the SAML nitty-gritty, you can use a 3rd party provider like Okta as an intermediary that will consume the SAML responses from the IdP (used by your external customers) and then convert that assertion into an Open ID token (JWT). In this case, Okta will act as an IdP (Authorization server) to your web app and generate ID tokens.
Your app will then need to implement the Open ID connect login flow.
You can refer to http://developer.okta.com/code/javascript/okta_sign-in_widget_ref for this.
We want to deeply integrate OneDrive with our web app in order to handle document and storage data. However, we want the users not to log in twice. I'm not sure whether this is possible, but I've been reading about SSO and SAML and it seems like it's the way to go.
Is it possible, and if so, is Single Sign On the way to go?
Single Sign-On (SSO) is a great solution for user experience when web applications are hosted on different domains. SAML as a standard was developed for cross domain authentication to solve this use case. You will need an Identity Provider (IdP) server that handles authentication of users to your web application and then the IdP Server issues SAML assertions to your web application and OneDrive. Your application in this architecture will be a Service Provider (SP) that will consume SAML assertions, as well as OneDrive is a SP that consumes SAML assertions. There are a number of SSO/Federation vendors that provide the IdP Server.
As far as implementation, once you have chosen and installed the IdP Server, you will need to implement your web application to consume the SAML assertion and configure the IdP Server as a connection. OneDrive will simply be a configuration as it already supports SAML and WS-Federation.
In addition to SAML as a protocol, there are other standards with respect to SSO/Federation such as OpenID Connect (OIDC) and OAuth2. When choosing a IdP Server solution you may want to look at these other protocols that can solve additional use cases. SAML works well for web applications and the use case you have described. OIDC and OAuth2 are better suited for secure APIs and native mobile applications.
Another consideration when looking at an IdP Server is how authentication is to be performed. Options for authentication could be using Kerberos/IWA if all clients are on a common domain, or authentication using a Login Form. You may also want to look at MFA support when looking at an IdP Server as part of the SSO solution.
I need to implement a SAML based authentication module and I am looking for answers to some basic question related to SAML. I tried searching for answers but couldn't find detailed information.
Resources to be protected is a SaaS based web application. Design I have received require4s building an authentication module using OpenAM, Ping, etc. Any access to web application will get authenticated through authentication system via SAML.
Questions that I have in this regard are:
If I understand correctly, SAML request contains a username. When someone first access web application, application has no information about user, how will it generate an SAML request then?
Once a SAML response is received by application, do subsequent access of web application by user also need to be routed and validated via authentication system?
Web application can interact with other sub-systems via web services or api calls. How can authentication context be passed to those systems.
No, the AuthnRequest does not have to contain a user name. It may, but in most cases it doesn't.
No, once the SAML response is received, the application typically set a cookie to create a local session.
The SAML Assertion can be passed to other services that the application uses. This is a non-trivial setup, but possible.