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)
Related
I know that you can define scopes for Google OAuth2, but can you define scopes for Google SAML?
I have read Google SAML docs and also some standard information about Google SAML, but wasn't able to get any info on it.
Short answer: No.
SAML is a different protocol where an identity provider grants access to a service. Since the SAML protocol only supports identity information it doesn't support OAuth 2.0 scopes, but SAML applications can request additional scopes through a regular consent screen after the user accesses the service.
Actually, OAuth is an authorization process where is mainly OAuth 2.0 is designed as an authorization protocol permitting a user to share access to specific resources with a service provider.
OAuth handles authorization, and SAML handles authentication.
On the other hand, SAML is typically used for SSO in government and enterprise applications (identity management) which does not require scopes because it is an authentication process.
Regardless, OAuth2 does not support SSO. And SAML tends to be specific to a user, while OAuth tends to be specific to an application.
Moreover, Google Cloud platform has the option to use OpenID connect where Google's OAuth 2.0 APIs can be used for both authentication and authorization.
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.
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.
Im using Janrain at the moment and dont know much about OAuth.
Could someone explain the differences between these two?
Janrain is using OpenID, so the user must get an identity with an OpenID provider. You already know how it work: User interacts with a provider that prompt for credentials. OpenID is a good solution if you want a Sign-In system that accept existing accounts from OpenID providers.
In the case of OAuth, it can be completely transparent to the end-user. OAuth works with Tokens and each token grants access to a specific site or resources, it's all about "authorization". You can also configure a token to expire after a defined duration. OAuth can also be used for Login, that's how Facebook works.
Example with OAuth:
Your website use Janrain for authentication, and now, you want to allow users to import photos from Facebook, but the user provider is Google (for example). You will redirect the user to Facebook for authentication and the user will be asked if he want to grant access to your website. If the user agree, he will be sent back to your website and in background, you'll get a Token from Facebook which must be used in future communication to validate actions. At no point the user shared username and password with your site.
I recommend you to read on OAuth. You can see a really good guide here, for both OAuth 1.0 and 2.0.
Janrain Engage is a set of widgets and backend technology to support a variety of identity providers who may be authenticating through various flavors of openid and oauth. Shielding you from implementing the protocols required to support the over 20 identity providers that Janrain supports.
There is no difference between Janrain and OAuth. Janrain is not a particular protocol for social sign in. Janrain creates a set of API's that work with both OpenID and OAuth - so you don't have to know the difference.
like Kevin said, Janrain's Social Login is back-end technology that supports a variety of identity providers who may be authenticating through various flavors of openid and oauth.
So there really is no difference between Janrain and OAuth, it's just that Janrain uses whichever technology the provider is using in their social API - OpenID and/or OAuth.
The problem is I have an standard SAML 2.0 Web-Profile IDP (a customized Shibboleth) that I can authenticate to Google Apps, nicely, but Microsoft decided to embrace-and-extend again, with WIF, so it seems things doesn't work off-the-shelf to have web SSO (SingleSignOn) with Sharepoint.
At least all the documentation show only how to integrate with AD FS STSs, or how to write your own STS as the protocols around claims exchange aren't standard.
From the overviews it seems feasible to have my IDP being called (redirected to) and returning the SAML response as a forced post, as usual, but it seems hard to tell WIF to just process the simple response we serve.
Thanks,
ADFS v2.0 does support SAML 2.0.
If the SP STS doesn't support this, then simply add ADFS as a trusted provider to the SP STS.
I believe that ADFS 2010 only supports WS-Federation Passive Requester Profile -- ie, no SAML 2.0 Web SSO support.
SAML 2.0 Web Profile support is possible I believe but you'll need to use a 3rd Party product like PingFederate for SAML 2.0 support unless you want to write quite a bit of custom code.
Hope this helps -
Ian