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
Related
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
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 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.
I am getting a strange error from ADFS 2.0 event Log as follows:
"The Federation Service could not fulfill the token-issuance request because the relying party 'https://my-relying-party' is missing a WS-Federation Passive endpoint address.
Relying party: https://my-relying-party
This request failed.
User Action
Use the AD FS 2.0 Management snap-in to configure a WS-Federation Passive endpoint on this relying party."
This happens after SAML response is verified successfully by ADFS 2.0 but apparently fails to issue a token for the relying party application.
I configured in ADFS 2.0 both IDP and SP as SAML 2.0 so I don't understand why is WS-Federation endpoint is expected?
Any help will be appreciated.
Is your web application talking the WS-Federation protocol or the SAML protocol (SAML-P)? If your web application is based on WIF, then you are using WS-Federation. Note that both protocols use SAML tokens.
If your application talks the WS-Federation protocol, then in your AD FS Relying Party Trust you need to set the WS-Federation endpoint(s). If it talks the SAML protocol, you need to set the SAML protocol endpoint(s).
Based on your error message, your application probably talks WS-Federation, therefore you need to set the WS-Federation endpoint.
The integration between your SAML 2.0 SP (ADFSv2) and your RP Application is done via WS-Federation Passive Requester Profile. So you'll need to setup your application to receive the WS-Fed Response and parse it appropriately. You'll also have to configure ADFSv2 to generate this message as well (per the error message you received).
Hope this helps -
Ian
You need to add the web application url to the endpoints in the properties of you relying party.
add ws-federation passive reference manually or in federation file will solve the problem.
Please let me know if you need detail guidance.