I implemented authentication and authorization using Identity server 4 with OIDC to allow clients accessing our application to get the necessary tokens to access our resource server (web APIs). This is the current architecture :
Identity Server 4 using my custom DB to authenticate users
Resource APIs (ASP.NET Core)
Angular 2 front end
I need to implement SSO, where users from other systems will pass SAML2 assertions from their identity providers to allow them to access our resource APIs without logging in to our application.
I have some confusion about where this step will happen, and what will be the workflow, will our identity server be involved in this process and how to implement that using Identity Server 4.
Right now there is no SAML2 support for ASP.NET Core.
If you are using IdentityServer3, you can act as a SAML2 SP via the Kentor authentication middleware. This is not available for ASP.NET Core yet.
Generally speaking - you cannot use SAML2 to secure APIs - it is a protocol for web based SSO - not API access.
Related
Assume we have the following entities:
User Agent (Browser)
IDP
Web Application (SP1)
Resource Portal (SP2)
The goal is to have the Web Application (SP1) being a "Front End" for the User, allowing them to access Resources through the Web Application (SP1) from the Resource Portal (SP2), without the user directly interacting with SP2. SP1 would therefore act as a kind of "Proxy" for SP2 and impersonate the logged-in user for the proxied requests.
Does SAML support this kind of use case? Is there any way to propagate the Security Context which was established on SP1 to SP2 (or any other mechanism that would allow the impersonated requests)? Based on my current understanding, the user would still need to establish a security context for SP2.
SAML doesn't really care what you do with the assertion. As the SP, you can choose how you wish to use that assertion, and how to communicate it further upstream.
If it were me, I would use a standard SP token provider (Ping, Okta, etc.) to consume the IdP's SAML. Switch SP1 and SP2 to use OIDC and OAuth respectively, and then use the access token from the OIDC flow on the backend API calls.
After successfuly authenticated via IDP, you have to perform a local authentication based on the assertions you received.
If you are are working on asp.net core application, you can use shared cookie concept and share the auth cookie which is created by local SP1 login with SP2. You can use Data Protection Service to store the shared key.
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’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.
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've been dropped into a hot potato project...an external entity produced a SOA architecture and we need to implement it now.
Using Drupal as a CMS and starting point of the architecture.
Here's what I think we need to do:
Authentication server
People register through the drupal site. We'd like to reuse the identity created for other (future) services, through a REST API
a) Can I add users to WSO2 Identity Server via a (REST) API?
b) Can I query WSO2IS to authenticate users via a (REST) API (creating a SSO env)?
c) Can I create re-usable profiles in WSO2IS, accessible through a (REST) API?
d) Can I authenticate drupal access via WSO2IS through a (REST) API?
e) Can I query the XACML policies via a (REST) API so that access to a requested service can be evaluated?
Other REST APIs we're going to build would use the OAuth functionality of WSO2
The architecture mandates each an authentication, a profiles and a policy (authorization) with XACML (...) module. The alternative is to build it all ourselves but I think we won't have the time for this, but I need to understand if we can do the above mentioned things to make a decision if WSO2IS is a good choice for our needs.
I have read the available documentation, browsed the help system, installed WSO2IS and checked out the interfaces, but couldn't find the responses. The only thing I managed to do is create the OAuth server.
Please find my answers..
a) Yes.. WSO2 Identity Server supports SCIM which is the standard approach for identity provisioning. Also there are web service APIs, that expose user management functions. You can front those web service API using WSO2 APIM and can expose as REST API.
b) Yes.. Apart from REST and web service API, Identity Server supports for authentication methods such as SAML2SSO, OpenID, IWA and so on.
c) Yes.. same as a) you have both options SCIM or Web service API fronted with APIM
d) There is an authentication framework in the WSO2IS, that users can be authenticated with different server.. Basically WSO2IS can act as federated IDP that application knows only to talk to WSO2IS.. WSO2IS can authenticate users from any other IDP, It can be drupal as well
e) Yes.. XACML is supported by WSO2IS... Its PDP API has been exposed via web service API.. but not as a REST API.. but as i mentioned earlier, you can expose it as REST using APIM. However REST support for XACML would be available with the further release