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.
Related
I have a Keycloak server that is functioning as my identity provider, using X.509 authentication to the users in my realm. I have successfully configured this as an external identity provider (SAML 2.0) to an ADFS server since I'm trying to allow access to an IIS-hosted web application through Web Application Proxy.
My current effort is to configure the claim rules to map the incoming SAML assertion attributes to internal Active Directory user accounts, so that ADFS/WAP can perform integrated Windows authentication internally once the external authentication is mapped to an internal user.
Most of the search results I've found address the exact opposite, assuming that I've authenticated with ADFS and need to map LDAP attributes to an outgoing claim.
Can anyone provide help, or direct me to a good source?
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.
to make long story short. Customer has both SP (referred as SP1) and an IDP. We are integrating our application (referred as SP2) to serve a protected resource. The resource will be available after the principal identity has been verified at IDP - typical SSO service. The following scenario would like this:
1. Pricipal enters SP1.
2. No security context has been created for the user yet, so he logs to IDP.
3. After a sucessful login, the user tries to access a resource on SP2 from SP1.
4. Request comes to SP2, which needs to verify principal identity.
5. SP2 tries to log in to IDP (HTTP Redirect Binding).
6. IDP verifies there is a security context and does not offer a login form but strikes back with assertion.
7. Resource is served.
Question 1 - For testing I am using shibboleth IDP and oiosaml java libraries for SP2. How does IDP (step 6) verify that use is logged in? Is it checked via presence of some cookie? Is it vendor specific check?
Question 2 - SP2 IP is not external so we would need to create a tunnel between SP1 and SP2 and between SP1 and SP2. Is there any standard scenario to verify principal authority without hitting IDP (step 5)?
As far as I know it is not specified how the IDP keeps track of security contexts. But I have never seen anything else than cookies.
I'm not sure you need the tunnel. There will not be any direct communication between SP1 and SP2 only between the SPs and IDP. And provided you use POST binding to deliver the SAML assertion there will not be a direct communication there either. In this case all communication would go over the browser.
This means that the browser must be able to connect to all of the nodes but the nodes does not need connectivity to eachother. Provided you use POST binding and not Artifact Binding.
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.
These are numerous technologies and buzzwords used for single sign-on with Microsoft services.
Can someone explain ADFS, WIF, WS Federation, SAML, and STS (Security token service), including where and when each is being used.
ADFS (Active Directory Federation Services) - Off-the-shelf Security Token Service (STS) produced by Microsoft and built on Windows Identity Foundation (WIF). Relies on AD for authentication. Can be used in active (SOAP web services) or passive (web sites) scenarios and supports SAML tokens, WS-Federation, WS-Trust and SAML-Protocol. It can be used as an Identity Provider (against AD) or as a Federation Provider.
http://technet.microsoft.com/en-us/library/adfs2(v=ws.10).aspx
WIF (Windows Identity Foundation) - The .NET library used to drive claims-based authentication in .NET applications and relying parties. It can also be used as a WS-Trust client and to a build custom STS.
http://msdn.microsoft.com/en-us/security/aa570351
WS-Federation - A protocol used by relying parties and an STS to negotiate a security token. An application requests a security token from an STS using WS Federation, and the STS returns (most of the time) a SAML security token back to the application using the WS Federation protocol. This is usually via HTTP (GETs and POSTs and redirects). Contrast this with WS-Trust, which is completely web service-based.
http://msdn.microsoft.com/en-us/library/bb498017.aspx
SAML Tokens (Security Assertion Markup Language) - This is simply the XML format used for security tokens, that typically capture user information (claims) and other relevant security-related data (signatures, token issuer, etc). The token is used by the application to authenticate users and drive application behavior (e.g. authorization). SAML Security Tokens are signed for integrity and optionally encrypted so only RP and STS can see its contents. In ASP.NET web sites using WIF, the token is by default encrypted and chunked into cookies, but this can be changed.
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
STS (Security Token Service) - As described above, the STS is the broker that sits between a relying party application and the user. An STS is an issuer of security tokens. "Issuer" is often a synonym of an STS. STSs are configured in two roles: as identity providers (IdP) when they authenticate users or as federation providers (FP) when they sit in the middle of a trust chain and act as "relying parties" for other IdPs. IdPs need a way of authenticating users. Some (like ADFS) use Active Directory, others use custom databases like SQL Server Membership (not ADFS). If the user properly authenticates, the STS will issue a security token.
http://msdn.microsoft.com/en-us/library/ff650503.aspx
http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html#_Toc212615442
Hopefully this helps. There are a lot of concepts and pieces to understand in claims-based authentication. To get a full understanding, you should check out A Guide to Claims-Based Identity and Access Control.
From a big picture viewpoint:
Assume an ASP.NET browser-based application that requires authentication and authorization.
The application can roll its own or it can outsource it.
WIF is a .NET library that allows ASP.NET to implement this outsourcing.
It talks to an STS (ADFS is an instance of an STS) which authenticates against an identity repository and provides authorization information in the form of claims. An STS provides a set of signed, trusted claims.
The protocol used between WIF and ADFS is WS-Federation.
If the STS was Java based (e.g Ping Identity or OpenAM), then WIF would use the SAML protocol for communication. ADFS also supports SAML to enable federation.
(Federation e.g. allows a user in a Java oriented company A to access the ASP.NET application in a .NET oriented company B by authenticating against A's identity repository. Company A and company B trust each other in a federation sense.)
This post is aimed at clarifying SAML Tokens, supported in ADFS 2.0, and SAML protocol, not supported until ADFS 3.0, the version of ADFS in Windows Server 2012 R2
1) The SAML protocol is not supported prior to ADFS 3.0
2) .net 4.5 based WIF applications require using the WS-Fed protocol and currently do not support SAML-Protocol
3) SAML Tokens are XML based. SAML tokens are supported in ADFS 2.0 and previous versions. ADFS 1.0. 1.1. and 2.0 only support the SAML Tokens, not protocol
4) If you are using WIF, WS-Fed (protocol) is required - so you could do the following:
SAML Protocol <---> ADFS <----> WS-FED <----> WIF (.net 4.5)
From Wiki:
• ADFS 1.0 - Windows Server 2003 R2 (additional download)
• ADFS 1.1 - Windows Server 2008 and Windows Server 2008 R2.
• ADFS 2.0 - Windows Server 2008 and Windows Server 2008 R2 (download
from Microsoft.com)
• ADFS 2.1 - Windows Server 2012.
• ADFS 3.0 - Windows Server 2012 R2.