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]
Related
Currently looking to federate servers that use AD. First thought was to use ADFS to manage service requests across domains and realms. That being said the application must have access to Kerberos tickets for a specific use case.
Does AD FS use Kerberos at any point or is it it's own totally redesigned ticketing system? If so can you create a hybrid application that can authenticate using ADFS and request tickets using Kerberos?
ADFS simply provides a federation service on top of AD i.e. support for protocols like WS-Fed and SAML.
The Kerberos protocol remains part of AD.
Once authenticated ADFS provides either a SAML 1.1 or 2.0 token that contains the claims.
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.
I am evaluating different protocols and software packages for my SSO project and I was thinking about the pros and cons of making an SSO system with SAML and one with something like CAS or Shibboleth. I couldn't really find any reason why I should choose SAML over Shibboleth or CAS since these two SSO solutions not only support SAML, but also many more functions that I otherwise have to implement.
Any ideas?
The important thing that Shibboleth offers is that it has 2 servers, SP (Service Provider) and IDP (Identity Provider). The SP server communicate with any IDP sever over the network, simply and only with configurations you can get an SSO working perfectly and it respects the SAML norms.
For example, you have a site that can be authenticated from multiple companies credentials, each company has it's own identity system, you don't have to deal with how they connect to their systems (CAS, shibboleth idp ...) but only how to protect your data using SAML2, this is done by sharing metadatas over this federation.
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.
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.