Category Archives: HTTP Concepts

WS-Fed vs. SAML vs. OAuth vs. OpenID Connect

Identity protocols are more pervasive than ever. Almost every enterprise you would come across will have an identity product incubated, tied with a specific identity protocol. While the initial idea behind these protocols was to help enterprise employees use a single set of credentials across applications, but new use cases have shown up since then. In this post, I am going to provide a quick overview of major protocols and the use cases they are trying to solve. Hope you will find it useful.

WS-Fed & SAML are the old boys in the market. Appearing in the early 2000s they are widespread today. Almost every major SSO COTS product supports one of these protocols. WS-Fed (WS-Federation) is a protocol from WS-* family primarily supported by IBM & Microsoft, while SAML (Security Assertion Markup Language) adopted by Computer Associates, Ping Identity and others for their SSO products. The premise with both WS-Fed and SAML is similar – decouple the applications (relying party/service provider) from an identity provider. This decoupling allows multiple applications to use a single identity provider with a predefined protocol, and not care about the implementation details of identity provider per se.

For web applications, this works via a set of browser redirects and message exchanges. User tries to access the web application, the application redirects the user to the identity provider. A user authenticates himself, identity provider issues a claims token and redirects the user back to the application. The application then validates the token (trust needs to established out of band between application and IdP), authorizes user access by asserting claims, and allows the user to access protected resources. The token is then stored in the session cookie of user browser, ensuring the process doesn’t have to be repeated for every access request.

At a high level, there isn’t much separating the flow of these two protocols, but they are different specifications with each having its own lingo. WS-Fed is perceived to be less complex and light weight (certainly an exception for WS-* family), but SAML being more complex is also perceived to be more secure. At the end you have to look at your ecosystem including existing investments, partners, in house expertise, etc. and determine which one will provide higher value. The diagram below taken from wiki depicts the SAML flow.

OAuth (Open Standard for Authorization) has different intent (the current version is OAuth 2.0). It’s driving force isn’t SSO but access delegation (the type of authorization). In simplest terms, it means giving your access to someone you trust, so that they can perform the job on your behalf. E.g. updating status across Facebook, Twitter, Instagram, etc. with a single click. The option you have is either to go to these sites manually or delegate your access to an app which can implicitly connect to these platforms to update status on your behalf. Flow is pretty simple, you ask application to update your status on Facebook, app redirects you to Facebook, you authenticate yourself to Facebook, Facebook throws up a consent page stating you are about to give this app right to update status on your behalf, you agree, the app gets an opaque access token from Facebook, app caches that access token, send the status update with access token to facebook, facebook validates the access token (easy in this case as the token was issued by Facebook itself), and updates your status.

OAuth refers to the parties involved as Client, Resource Owner (end-user), Resource Server, and Authorization Server. Mapping these to our Facebook example, Client is the application trying to do work on your behalf. Resource owner is you (you owe the Facebook account), Resource Server is the Facebook (holding your account), and Authorization Server is also Facebook (in our case Facebook issues the access token using which client can update status on Facebook account). It perfectly ok for Resource Server and Authorization Server to be managed by separate entities, it just means more work to establish common ground for protocols and token formats. Below screenshot depicts the OAuth2 protocol flow

Web community liked the lightweight approach of OAuth. And hence, the question came – can OAuth do authentication as well, providing an alternative to heavy lifting protocol WS-Fed and SAML? Enter OpenID Connect is about adding Authentication to OAuth. It aims at making Authorization Server do more – i.e. not only issuing access token, but also an ID token. ID token is a JWT (JSON Web Token) containing information about authentication event, like when it did it occur, etc. and also about the subject / user (specification talks of a UserInfo Endpoint to obtain user details). Going back to the Facebook example, here the client not only relies on Facebook to provide us an opaque access token for status updates, but also an ID token which client can consume and validate that the user actually authenticated with Facebook. It can also fetch additional user details it needs via Facebook’s UserInfo Endpoint. Below diagram from OpenID connect spec indicates the protocol flow.

OP in the above case is OpenID Provider. All OpenID Providers have the discovery details published via JSON document found by concatenating provider URL with /.well-known/openid-configuration. This document has all the provider details including Authorization, Token and UserInfo Endpoints. Let’s see a quick example with a Microsoft offering called Azure Active Directory (Azure AD). Azure AD being an OpenID Provider, will have the openid configuration for its tenant demoad2.onmicrosoft.com available at https://login.microsoftonline.com/demoad2.onmicrosoft.com/.well-known/openid-configuration.

'Coz sharing is caring

URL redirection

URL HTTP Redirection

URL http redirection is an automatic URL change operation from one URL to another URL.

URL redirection

URL page redirection is an automatic URL change operation from one URL to another URL.

This redirection is done for the following reasons:

  1. Redirect from old obsolete URL to a new updated URL.
  2. Redirect from old obsolete domain to a new domain.
  3. Redirect from non www domain name to a www domain name.
  4. Redirect from short URL name to a long URL name – URL shortening service.
  5. URL shortening service will allow the user to insert a short URL and be redirected the the long URL that has the real page contents.

The user may reach the old URL from an old external links or a bookmark by the site’s webmaster who adds a script.

Server side redirect

Server side redirection is done in the server, by configuring the Apache / IIS server software or by using PHP / ASP / ASP.NET script.
This is the preferred way to redirect URLs, since you can return HTTP 301 Moved Permanently status code.
Search engines use the 301 status to transfer the page rank from the old URL to the new URL.

Client side redirect

Client side redirection is done in the web browser of the user, by using HTML meta refresh tag or by Javascript code.
Client redirect is less preferred, since it does not return HTTP 301 status code.

Where to put redirect code

Domain
name
Hosting
server
Redirect code
placement
not changed not changed old page on same server
not changed changed old page on new server
changed not changed old page on same server
changed changed old page on old server

* Only with .htaccess redirect: add redirect code to httpd.conf
file or to .htaccess file.

HTTP status codes

Status code Status code name Description
200 OK successful HTTP request
300 Multiple Choices
301 Moved Permanently permanent URL redirection
302 Found temporary URL redirection
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
404 Not Found URL not found

HTTP 301 redirect

HTTP 301 Moved Permanently status code means a permanent URL redirection.

The 301 redirect is the preferred way to redirect URLs, since it informs search engines that the URL has moved for good, and search engines should put the new URL page in the search results instead of the old URL page and transfer the new URL page, the page rank of the old URL page.
The 301 redirect can be done across domains or on the same domain.
Google recommends to use 301 redirect.

Redirect options

Redirect script Redirect side Old page file type Redirect URL or domain Old URL server type 301 redirect support
PHP Server-side .php URL Apache / Linux yes
ASP Server-side .asp URL IIS / Windows yes
ASP.NET Server-side .aspx URL IIS / Windows yes
.htaccess Server-side all URL / Domain Apache / Linux yes
IIS Server-side all URL / Domain IIS / Windows yes
HTML canonical link tag Client-side .html URL all no
HTML meta refresh Client-side .html URL all no
HTML frame Client-side .html URL all no
Javascript Client-side .html URL all no
jQuery Client-side .html URL all no

redirect script – the scripting language that is used for the redirection.

redirect side – where the redirection takes place – server-side or client-side.

old page file type – the type of the old URL page that can can contain the scripting language of the redirect code.

redirect URL or domain – does support URL redirection of a single web page or domain redirection of a whole website.

typical old URL server type – the typical software and operating system of the server.

301 redirect support – indicates whether permanent 301 redirect status response can be returned.

PHP redirect

Replace old-page.php code with redirection code to new-page.php.

old_page.php:

<?php 
// PHP permanent URL redirection 
header("Location: http://www.mydomain.com/new-page.php", true, 301);
exit();
?>

The old page must have .php file extension.

The new page can be with any extension.

Apache .htaccess redirect

.htaccess file is a local configuration file of the Apache server.

If you have permission the change the httpd.conf file, it is better to add the Redirect directive in the httpd.conf instead of the .htaccess file.

Single URL redirect

Permanent redirect from old-page.html to new-page.html.

.htaccess:

Redirect 301 /old-page.html http://www.mydomain.com/new-page.html

Entire domain redirect

Permanent redirect from all domain pages to newdomain.com.

 .htaccess file should be at the old website’s root directory.

.htaccess:

Redirect 301 / http://www.newdomain.com/

ASP redirect

old-page.asp:

<%@ Language="VBScript" %>
<%
' ASP permanent URL redirection
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.mydomain.com/new-page.html"
Response.End
%>

ASP.NET redirect

old-page.aspx:

<script language="C#" runat="server">
// ASP.net permanent URL redirection
private void Page_Load(object sender, EventArgs e)
{
    Response.Status = "301 Moved Permanently";
    Response.AddHeader("Location","http://www.mydomain.com/new-page.html");
    Response.End();
}
</script>

HTML meta refresh redirect

HTML meta refresh tag redirection does not return 301 permanent redirect status code, but considered by Google as a 301 redirect.
Replace old page with redirection code with the URL of the page you want to redirect to.

old-page.html:

<!-- HTML meta refresh URL redirection -->
<html>
  <head>
    <meta http-equiv="refresh" content="0; url=http://www.mydomain.com/new-page.html">
  </head>
  <body>
    <p>The page has moved to: 
    <a href="http://www.mydomain.com/new-page.html"> this page</a>
    </p>
  </body>
</html>

Javascript redirect

Javascript redirect does not return 301 permanent redirect status code.

Replace old page with redirection code with the URL of the page you want to redirect to.

old-page.html:

<html>
  <body>
    <script type="text/javascript">
    // Javascript URL redirection
    window.location.replace("http://www.mydomain.com/new-page.html");
    </script>
  </body>
</html>

jQuery redirect

jQuery redirect is actually another type of Javascript redirect. jQuery redirect does not return 301 permanent redirect status code.

Replace old page with redirection code with the URL of the page you want to redirect to.

old-page.html:

<!DOCTYPE html>
<html>
  <body>
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
    <script type="text/javascript">
    // jQuery URL redirection
    $(document).ready( function() {
      url = "http://www.mydomain.com/new-page.html";
      $( location ).attr("href", url);
    });
    </script>
  </body>
</html>

HTML canonical link tag redirect

The canonical link does not redirect to the preffred URL, but it can be an alternative to URL redirection for websites that most of the traffic arrives from search engines.
HTML canonical link tag can be used when there are several pages with similar content and you want to tell the search engines which page you preffer to use in the search results.
Canonical link tag can link to the same domain and also cross-domain.
Add the canonical link tag to the old page to link to the new page.
Add the canonical link tag to the pages that you preffer not to get search engines traffic to link to the preffered page.

The canonical link tag should be added in the <head> section.

old-page.html:

<link rel="canonical" href="http://www.mydomain.com/new-page.html">

HTML frame redirect

In frame redirection the new-page.html file is viewed by an html frame.

This is not a real URL redirection.

Frame redirection is not search engines friendly and is not recommended.

old-page.html:

<!-- HTML frame redirection -->
<html>
  <head>
    <title>Title of new page</title>
  </head>
  <frameset cols="100%">
    <frame src="http://www.mydomain.com/new-page.html">
    <noframes>
      <a href="http://www.mydomain.com/new-page.html">Link to new page</a>
    </noframes>
  </frameset>
</html>
'Coz sharing is caring