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.
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.
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.
When using a passive client (say web browser) and are using WS Federation with an STS such as ADFS, SSO is achieved to the relying parties. Is this apart of the WS Federation specification (that is, when using passive clients SSO will be achieved with WS Federation) or is this an implementation detail of ADFS (that is, ADFS sets a cookie so you only need to authenticate to ADFS once.. just beacuse the Microsoft developers thought it would improve user experience)?
It is a standard which is also supported by many other products.
https://en.wikipedia.org/wiki/WS-Federation_Passive_Requestor_Profile
http://janbernhardt.blogspot.com/2014/12/understanding-ws-federation-passive.html
WS-Federation Passive Requestor Profile is a Web Services specification - intended to work with the WS-Federation specification - which defines how identity, authentication and authorization mechanisms work across trust realms. The specification deals specifically with how applications, such as web browsers, make requests using these mechanisms. In this context, the web-browser is known as a "passive requestor." By way of contrast, WS-Federation Active Requestor Profile deals with "active requestors" such as SOAP-enabled applications. WS-Federation Passive Requestor Profile was created by IBM, BEA Systems, Microsoft, VeriSign, and RSA Security.[1]
I am creating a java application to implement SSO (SAML) using ADFS. I am not sure if SAML can be done using ADFS alone. While installing ADFS, I noticed that it required configurations of relying party and claim providers trusts (which are basically the SP and IP, right?). I am confused as to whether to have SP and IP in the java application, or just leave it to the ADFS to handle.
Any help would be greatly appreciated. Thanks!
Your Java application needs a SAML stack and becomes the SP.
Refer: SAML : SAML connectivity / toolkit for some ideas if you don't have one.
ADFS (which handles SAML 2.0) can then function as the IDP.
You will also have to configure the claims in ADFS - which correspond to the SAML assertions.
Your Java application will be a Service Provider (SP) that receives identity from an Identity Provider (IdP) server. In the use case you have outlined, ADFS will be the IdP Server. within your application you will need to integrate a library (e.g. SAML stack) to process the SAML assertion. SAML requires configuration on both sides of the interface. There are a few open source options such as OpenSAML. Depending on your organization, you may want to look at a vendor provided solution as well for long term support.
I'am are trying to implement a Web SSO with claim based identity using WIF and AD FS 2.0 right now. Right now I have a existing ASP.Net application which delegates authentification to the AD FS 2.0 server and trust issued security tokens. That works just fine.
However, in the organization there is an existing JA-SIG Central Authentication Service (CAS) server which supports the SAML 2 protocol. I would like to replace AD FS 2.0 with the existing CAS service.
In my understanding WIF uses WS-Federation, which is like a container around a SAML token. Is it possible to use the plain SAML 2 protocol and it's bindings (redirect or POST)? If that is not possible (as I guess), a second alternative might be to use federate identity and federate AD FS 2.0 with CAS. Is that possible? There is little to no information about that on the web.
Thanks :-)
After some research I came up with the following issues. CAS 3.x supports SAML 1.1 tokens and the SAML 1.1 protocol including Web SSO. There is support for SAML 1.1/2.0 tokens in ADFS 2.0. However, only the SAML 2.0 protocol is supported. That means no out of the box federation between CAS and ADFS 2.0 is possible.
We are researching OpenSSO as an alternative now, which provides support for all necessary protocols including WS-Federation for attaching WIF clients.
Access control Service v2 (ACS v2) may be an option. It supports both SAML1.1 and 2.0 as well in addition to other ones like simple web token (SWT) etc. It then allows to translate tokens from the source system to the relying party format..
https://portal.appfabriclabs.com/Default.aspx