I’m having trouble understanding OpenID Connect actors/roles. I’m coming from using SAML. In the scenario I’m familiar with, the Service Provider is a web application with protected resources and the Identity Provider server is where users authenticate. With SAML, the typical client is a web browser although SAML also has the ECP profile where a non-browser client (such as a native application) can be used. I understand how all of those pieces work and their various flows.
I’m trying to apply that same understanding to OpenID Connect. My understanding is the OpenID Provider is the same as the Identity Provider. But what about the other pieces? Is the Service Provider the Relying Party? What’s the client then? The OpenID Connect documentation substitutes "Relying Party" with "client" and that’s throwing me off.
To me, coming from SAML, a client is either a web browser or, in the case of ECP, a native or mobile application. So what role is that kind of client in the OpenID Connect world?
Since OpenID Connect is built on OAuth, I've familiarzed myself with it but that hasn't cleared up this SAML to OpenID Connect confusion. Any help would be greatly appreciated. Thanks!
The term "Client" is a generic name that is inherited from OAuth 2.0 for an entity that requests, receives and uses tokens. OpenID Connect builds on top of that but since there's an identity token in play now, the Client is also called Relying Party.
The Relying Party (or Client) is really the same as the SAML Service Provider and the ECP, being the entity that relies on the IDP to provide user identity to it.
The Relying Party (or Client) can be any of a web application, a native application or mobile application.
Related
I'm trying to create a SAML IDP for the system I built. Probably I'm getting confused with concepts. My problem is as follows:
This system was built in SymfonyPHP which authentication is made by OAuth token. Nothing so special, the username and password are passed to the /auth endpoint and the request returns the token if the credentials are valid. It's working fine.
Now I have to integrate this credentials to a client system. Once the user is logged to my system, so it should be on the client side (like the "login with Google button). I've been searching and realized I should use SAML for that.
I installed the SimpleSAMLPHP and I'm trying to understand how to set it up as my IDP. Once it's made, I can create SPs for my clients systems.
Question: how to make the SimpleSAML use my existing service for authentication? Which module should I use?
With SimpleSAMLPHP acting as an IdP, you want to have a look at authentication modules. The latter is a component that encapsulates the mechanics of signing into the identity provider. For example, if you were trying to sign in to the IdP with your Facebook account, SimpleSAMLPHP ships a FB authentication module that does this for you.
If your existing service can be supported by one of the SimpleSAMLPHP modules, then you're all set. Else, you need to develop your own module.
There is an existing mechanism to log into a website. Now, external / remote SAML IDP is being added to facilitate SSO. The website uses other micro-services and components that provide data and functionality to the website.
Is there a way to have an existing mechanism of local identity username password credentials to continue to co-exist as an alternate strategy for authentication alongside remote IDP SSO while keeping rest of the services handling authorization in a semantic way (using a saml token)?
P.S. I looked at the options to implement existing auth mechanism as saml IDP, but building it seems complex even with the likes of shibboleth or openSAML libraries.
P.P.S. I haven't looked at possibility of reimplementing existing auth mechanism with openId connect to co-exist with remote saml idps.
Sure: one can provide a landing page to the user that gives a choice between using a local account or an account at a remote IDP.
We are in process of building a series of apps that will run offline or in very austere environments. We'll also be integrating with other 3rd party apps. Many of these will require logins so we're attempting to use SAML to handle login between them.
I found saml2-js:
https://github.com/Clever/saml2
And it seemed like a great starting point for both the SAML Service Provider and Identity Provider - but diving in I now see it does not implement the Identity Provider at all.
I already have a basic SAML Service Provider setup, but we need an Identity Provider that can run offline. Are there any Node or GoLang Identity Provider libraries we can use to implement this? If not, another recommendation?
Passport is the usual Node option but that's client side only.
There are a number of IDP's you can use e.g.:
Free: simpleSAMLphp / Shibboleth / identityserver4
Cloud: Auth0 / Okta / Azure AD
On-premises: ADFS
I want to implement SSO using Thinktecture Identity Server V3. The applications the I want to use this SSO are asp.net MVC apps. I was going through samples provided on the thinktecture wiki and am able to see two approaches:
1- Resource owner(providing credentials through application and calling Identity server using OAuth2Client Apis)
2- Using Owin middleware(Startup class) to call the Identity server.
In my case I wanted to calling Identity server login, but without using Owin. Do you any hints/sample on how to do that.
Thanks
If you don't want to use the Microsoft OpenId Connect middleware (and as a result OWIN) in your clients, you could initiate the login flow yourself by redirecting the user to the authorize endpoint.
Authorize endpoint: http://thinktecture.github.io/Thinktecture.IdentityServer.v3.Documentation/docs/endpoints/authorization.html
They guys behind IdentityServer have a client example showing some of the concepts if you want to handle it all yourself:
https://github.com/thinktecture/Thinktecture.IdentityServer.v3.Samples/blob/master/source/Clients/MvcFormPostClient/Controllers/AccountController.cs
I installed PingFederate on an AWS EC2 running Windows_Server-2008-R2_SP1-English-64Bit-Base-2014.04.09. I have a Java application that is using Spring Security for authentication.
I have read about how with PingFederate, I can set up an Identity Provider(IdP) and a Service Provider(SP). I have gathered that the IdP would be the Application User providing login credentials(the Identity) and passing this to the SP which has the Target Application apart of the SP in this diagram on this page here:
http://documentation.pingidentity.com/display/PF66/Service+Providers+and+Identity+Providers
This image also shows the Federated Identity Software on both sides of the IdP and the SP.
I have created an IdP and SP with my local PingFederate server just to see what the configuration options are and I am confused on which parts of this I actually need to be able to have a SSO for my Spring Security application.
My questions are:
Do I need an IdP and SP to implement that I am trying to do.
Right now our usernames and passwords are stored in a SQL Server, would I leverage this for PingFederate to use to authenticate the users?
Should I even be using Spring Security SAML for this or would another route be more appropriate?
Thanks for any help, I have reached out to PingFederate but my Regional Solutions Architect happens to be out until Friday.
I also apologize if I am completely off in my thinking, I am trying to wrap my mind around what is needed.
Presuming your goal is to establish federation between Ping and your application (in order to e.g. externalize authentication or enable single sign-on), your thinking is correct.
The Ping Federate serves as an Identity Provider (IDP) and you can configure it to connect to your SQL server, so that it can authenticate your existing users from there. IDP communicates with other applications which are called Service Providers (SP).
In order to connect to Ping your application therefore needs to be able to act as a SAML 2.0 Service Provider and using Spring SAML is a very good way to enable it to do so.
The typical flow of data between SP and IDP for single sign-on is similar to:
User accesses SP application which requires authentication
SP creates an AuthenticationRequest and sends it to IDP (using redirect in user's browser)
IDP processes the request and authenticates the user
IDP responds back to SP with an AuthenticationResponse message
SP processes the response and creates a session for the user based on the included data
There is an assumption being made that you need SAML between your Spring app and PingFederate. That is not true depending on how it is deployed and if you (see Andy K follow-up questions). You should check out the OpenToken Integration Kit for Java or perhaps the ReferenceID Int Kit from Ping as a possible solution. Much simpler to integrate than trying to hack together another SAML solution that may not be needed. However, I would recommend talking to your RSA who can give you the best approach for your scenario.