In a recent discussion with solution architects in my team, a topic came up on the differentiation between SAML and oAuth. While there were many analogy provided, I thought it was a good idea to come up with a blog post to discuss about it. And what else is a better way to restart blogging then writing about my favorite topic.
Lets first understand what SAML and oAuth are all about;
SAML – Security Assertion Markup Language is an umbrella standard that encompasses profiles, bindings and constructs to achieve Single Sign on, Federation and Identity Management. Its an XML based open standard format for exchanging authentication and authorization data between parties, especially between an identity provider and service provider. The single most important requirement that SAML addresses is web browser single sign-on (SSO). Single sign-on is common at the intranet level (using cookies, for example) but extending it beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies.
oAuth – oAuth is primarily about authorization to access resource. It, by itself, doesn’t deal with authentication. It works using Bearer Tokens. Bearer tokens are tokens that grant access to resources (identified by the tokens) without the need for cryptographic keys(Proof of Possession) of the entity(aka Bearer), in possession of the tokens. oAuth has been proven mechanism for authorization and is designed for scale.
When do you use SAML or oAuth?
SAML is designed to be used in Enterprise SSO scenarios where the use cases are
Within an enterprise
Enterprise to external partner
Enterprise to cloud.
oAuth on the other hand is used in scenarios where internet resources are to be accessed in scalable manner on different devices and platforms.
SAML has one feature that lacks in oAuth which is user identity information. The user information can be carried in the SAML token which in oAuth is requested by making an additional trip to IDP.
Let’s see few examples where SAML is used “effectively”
1. Office 365 Single Sign On – Most of you would have come across the need for having single sign on when using Office 365. What is a bigger nuisance than entering your credentials again and again when signing into your email, intranet and Skype for Business. In this case, Microsoft allows administrators to configure SSO using AD FS and SAML by syncing Active Directory profiles and then redirecting logged in users for authentication to AD FS. The SAML token carries much more information about the user than just authentication response and this makes SAML more flexible when used with Enterprise Systems.
2. Salesforce.com – Allowing users to access salesforce.com using their Active Directory credentials.
3. ServiceNOW – Allowing users to access ServiceNow cloud based application using their Active Directory credentials.
There are many more enterprise applications that support SAML standard.
Now let’s see few examples where oAuth is used “effectively”
1. eCommerce websites – In this scenario, if the commerce website doesn’t want the user to fill in all the information that could be made available through their social networking profile, they would allow the user to register through one of the oAuth based providers like FaceBook, Twitter, Google, Live. In this case, the user would be authorized to use their site based on the information provided by the authorization resource server. This can be temporary or permanent.
2. Apps on Mobile and Tablets – SAML has its limitation with native apps which is why oAuth comes into play with its lack of dependency on HTTP post body.
To summarize, SAML is authentication driven whereas oAuth is authorization driven framework. This is just tip of the iceberg and as we continue our journey towards identity and access management, lets explore more in my upcoming posts. Till then, keep watching this space for more.
While building a SharePoint 2013 environment, I came across this error when running SharePoint 2013 installation.
A system restart from a previous installation or update is pending
The pre-requisites wizard had successfully installed the required dependencies and restarted several times. And so did I manually restarted the server but in vain. Looks like this was due to a registry entry that did not clear the session state from pending restart to clear. So, change the following registry key and re run the installation. Lo and behold, the installation started. But make sure you have restarted the server before you make these changes to ensure any genuine pending request for restart are cleared.
Open the Registry editor (run > regedit)
•Navigate to this path “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager“
•Rename the “PendingFileRenameOperations” value to “OldPendingFileRenameOperations“
•Reboot the server
Now proceed with a clean install.