After reading about Microsoft's Claims-based identity, I don't understand what it brings more compared to OAuth (and therefore where is it better to use Claims-based identity rather than OAuth).
According to this Stack Overflow answer:
Claims-based identity is a way of decoupling your application code from the specifics of identity protocols [while] OAuth is a specific protocol.
This other answer claims that:
Claims-based security is required with OAuth
So it looks like:
Claims-based identity is more of an architecture while OAuth is a protocol.
Claims-based identity accepts multiple protocols, including OAuth.
OAuth uses Claims-based identity.
and obviously:
Claims-based identity can be used outside web applications,
Claims-based identity is Microsoft-oriented, which means excellent support in Microsoft products (such as SharePoint), but weaker support in other environments (such as a Python application hosted on a Linux server),
which means that there is a huge benefit of using Claims-based identity in corporate web, desktop and mobile applications within a company which relies heavily on Microsoft technologies and needs to provide authentication mechanism based on Active Directory and other providers, such as partner's OAuth providers.
Is my understanding of Claims-based identity right?
I cannot see anything incorrect in your part of the text.
You could also talk about claims as an: "signed attribute-name-value pairs". The issuer "claims" that it is correct. Attribute-value pairs itself pre-dates any new "claims" terminology and is widely used (under different names).
Yes, Microsoft is now fully Attribute-value pairs (claims if you insist on the nice word). Into the toe nails, even the native Kerberos token now has them. In the past it was only SIDs and privileges. In .NET everything is now ClaimsIdentity.
Related
I am implementing a SAML SSO solution (using OpenSAML 2.0) for a service provider w/a complex environment. The platform contains multiple entities ('Sites') and there are separate logins for each of the sites (i.e., user#site1, user#site2, etc.). Additionally, the roles/permissions available w/in these sites can vary...
<SiteA>
<Roles>Role1, Role2</Roles>
</SiteA>
<SiteB>
<Roles>Role2, Role3</Roles>
</SiteB>
<SiteC>
<Roles>Role1, Role3, Role4</Roles>
</SiteC>
In short, is this too much to ask of a SAML assertion, given that SAML is generally defined as an authentication (vs authorization) mechanism? I haven't been able to find any good examples of an identity provider assertion (ADFS) that supports this.
We are just getting started with implementing ADFS authentication, however are still getting our bearings in terms of how to integrate it with other applications and systems.
From what I can tell, the main supported authentication systems for many of the applications we use (I am specifically interested in Blackboard authentication at the moment) are ones like Shibboleth, OAuth, CAS, LDAP and each application's own authentication implication.
What I'm not sure, however, is if (and where) ADFS falls under these categories. Conceptually, it seems like a type of "Central Authentication System" (CAS), but is more similar to Shibboleth (also a federated identity management system). Do some of the main categories of authentication overlap each other? From the documentation, I can see:
AD FS provides Web SSO to federated partners outside your organization, which enables their users to have a SSO experience when they access your organization’s Web-based applications.
The Central Authentication Service (CAS) is a single sign-on protocol for the web. Its purpose is to permit a user to access multiple applications while providing their credentials (such as userid and password) only once. It also allows web applications to authenticate users without gaining access to a user's security credentials, such as a password. The name CAS also refers to a software package that implements this protocol
Shibboleth is among the world's most widely deployed federated identity solutions, connecting users to applications both within and between organizations.
My main question is this:
Is ADFS a type of one of those main implementations (like CAS)...
or is it a proprietary version of something like Shibboleth, but can be used interchangeably...
or does it fall in a category outside of one of of one of those systems (and hence need to be handled through a manual or custom process)?
Just to clarify:
Shibboleth is an Identity Provider (IDP) aka Security Token System (STS)
OAuth is an authentication protocol
LDAP is an Identity repository
An IDP authenticates against a repository using an authentication protocol.
ADFS is also an Identity Provider (IDP) aka Security Token System (STS)
I've not seen the term "CAS" used in this context.
Shibboleth and ADFS perform the same function and are (in a general sense) interchangeable.
In practice, they aren't because Shibboleth only supports the SAML 2.0 protocol whereas ADFS supports WS-Fed, SAML 2.0 and OpenID Connect / OAuth 2.0.
Some additions/updates to the accepted answer from rbrayb a few years later:
Shibboleth IdP is the reference implementation for SAML and also supports CAS and OpenID Connect.
Shibboleth SP is the SAML service provider from the same project.
CAS (Central Authentication Service) is another web-SSO protocol like SAML; it's also the name of the reference implementation, which also supports SAML, OIDC, etc.
OAuth is an authorization standard.
SAML, CAS, OpenID, Kerberos and other SSO protocols are based on the concept of a Trusted third party.
LDAP happens to be a service in which, in a given organization, most or everyone already has an account with a password. There is nothing inherently special about it as a server to authenticate against. It could just as well have been a telnet server or web server with basic auth or a SQL server; in any of these cases, the application has to collect the username & password and pass those through to the back-end authentication service, unlike SSO protocols. (LDAP happens to provide a vendor-neutral, non-interactively-focused interface for the authentication, which is part of the reason it's often put to this task rather than the others.)
(I originally tried adding this as a comment but comments do not support the formatting I wanted.)
I know that SAML can be used for user Authentication, but what about the permission levels a user has? Can it also be used for Authorization as well?
If not, what are the best alternatives for Open Source Authorization software?
SAML is a protocol that can be used for exchange of any information, including authorization-related "stuff". For example, in a very simple role-based access control scenario a SAML assertion issued by the identity provider can contain user's roles represented as attributes (or a single multi-valued attribute). The service provider can then extract the roles and use them to authorize access to some resource(s).
XACML is another protocol that is specifically geared to deal with some aspects of access control in an interoperable and declarative fashion. It is rarely used and it is considerably less popular than SAML.
oAuth is often used for authorization of access, especially in the REST world with APIs.
Both oAuth and XACML can coexist with SAML or be used independently.
SAML does not do authorization explicitly. It simply provides the attributes in the SAML token and it's up to the application as to how these are handled.
The same is true for WS-Federation.
For OAuth2, the "attributes" it provides are somewhat limited. And you still have to authenticate e.g. OpenID Connect.
This relates to, but I'm quite sure does not duplicate, my question: Looking for a secure and robust STS implementation
Since asking that, some input from business, and some research, has led me to believe that instead of implementing a secure token service to wrap my custom identity provider, I can delegate the issuing of tokens to the identity provider itself.
The identity provider is a WCF service that returns a collection of claims when it successfully authenticates a user, based on some identifying data for the user. E.g.
[ServiceContract(Namespace = "http://namespace")]
public interface IIdService
{
[FaultContract(typeof(IdServiceFault))]
[OperationContract]
ICollection<Claim> Authenticate(string idDatum1, string idDatum2);
}
where Claim is Microsoft.IdentityModel.Claims.Claim. I am currently stuck with a an example only quality STS implementation, as a web site project, but if at all possible, I would like to simply move the task of issuing and signing tokens into the identity provider, and eventually qualify it as a WS-Federation Identity Provider, that I can later include in my Azure Access Control's providers.
If this is possible, what do I need to do in the WCF service?
"One doesn't just knock together a WS-Federation Identity Provider" - there are a lot of necessary complexities involved, mostly to ensure the security, integrity and provability of the claims being asserted.
You do NOT want to get this stuff wrong - look at what happened at Target, Home Depot, Sony and others of late!
I strongly encourage you to read and re-read Michele Leroux Bustamante's "Building A Custom Security Token Service" article until you thoroughly understand the role of an STS and the various complexities involved in doing so.
Note that in order to build a secure STS you'll need to support SAML, WS-Security, WS-Trust, WS-Federation and use SSL for secure transport of tokens and data. You'll need to carefully implement the various stages of the communication protocol necessary to permit the federation of identity information.
Once you've deeply grokked the subject matter, you'll have a much better understanding of why it's likely a good idea to build an STS as a façade service that sits alongside/in-front-of your existing Identity service - rather than "pollute" your existing service with the considerable complexities involved in building an STS.
If this all seems like a heck of a lot of work, it is (and it should be - security is really, REALLY hard!).
I would strongly recommend you consider using Thinktecture's Identity Server instead of building your own. The awesome Dominick Baier & team have done an awesome job of building a robust, well engineered, open-source Identity Server that supports WS-Fed as well as OpenID, OAUTH, etc.
Given that SAML 2.0 supports the "federation" concept, and given that well-know players like Google use SAML, can someone explain why some other services (e.g., stackoverflow) use OpenID? Is that just a historical reason?
First I should say Google is a SAML provider and as well as an OpenID Provider.
In case of stackoverflow, if they are willing use SAML 2.0 for SSO, then they need to couple stackoverflow with Google or any other SAML Provider in advance. And when stackoverflow has coupled to many SAML providers, when a user tried to login, stackoverlow needs a mechanism to figure out to which identity provider it should redirect the user for authentication. (you may use SAML 2.0 Profiles, section 4.3 Identity Provider Discovery Profile). But anyways this is going to be a painful implementation.
But with OpenID, it has its own discovery profile, stackoverflow doesn't have to know the Identity Provider in advance, no direct coupling. So they are using the correct protocol.
As far as my knowledge:
OpenID allows a web (stackoverflow) to use identity from various OpenID providers (and there is no sharing identity on this)
SAML (/w federation) allows an Identity to be shared in various service providers/web(s)