Monday, March 18, 2019

Understanding concepts - OpenId, OAuth and SAML

I was going through some of the forums related to security concepts and found one topic which is very much communal, and many people posted questions about their confusion on the terms related to Authorization, Authentication and Security protocols. 

So, I thought to write something about these terms in layman, which is more towards the concept and less towards technical aspects. 

Before we start, let's have a look at the question, which really lighten the spark in me - - What's the difference between OpenID and OAuth? Hope you are with me to get started.

Well, one of the major aims of any application is to make it secure and easy to use without imposing much work on the end user. Now, in order to fulfill this aim, we have to look into a few of the major security aspects in terms of protocols, usage and scenarios. And that's why this article is.

What is Authentication and Authorization?
In simple terms, authentication is the process to verify whether the user is the intended user rather than any fake identity. In fact, it is the same who it claims to be. Whereas authorization deals with accessing resources. Authorization tells which resources user can access and till how much extent. So, in most of the applications these both terms run hand-in-hand.

SSO is an authentication mechanism in which user can log in to one application using some sort of credentials and accesses another application without re-entering the credentials. In this scenario, same credentials can be used to log in to another application. 

Best real-world example can be – our internal corporate portal in which we can find links of many other applications. So, once we are logged in to the portal, we need not to authenticate our self again and again to use other applications (apart from few more secure apps).

Benefits of going with SSO are quite pleasant as:
  • User needs to remember only one set of credentials and the same can be used with other related applications
  • Maintaining credentials in one place saves space as well as reducing cost.
How to implement this SSO?
Here come the security protocols, or say jargons like SAML, OAuth, OpenID, etc. Confused? Scratching your head? 
No need to worry. Sit back and relax. We do have ready made APIs to rescue us. 😊

Now before jumping straight into coding, let’s first get the gist of these jargons.

OpenID is used for authentication purpose and allows us to use an existing account to log in to numerous sites. It was founded by a non-profit organization named as OpenID Foundation. Today this open standard is accepted by many giants like Microsoft, Google, Facebook, AOL, and many more.

How to get an OpenID account?
Getting an OpenID account is very simple as it can be obtained through any of the OpenId providers (as listed above). Once the account is obtained, the user can log in to any web site which supports OpenID authentication. 

As an example, you can imagine your account accepting a google email id for authentication. In this example, Google is the Identity Provider and is the Relying Party. Below figure will you clear idea on what we just understood.

Please note that all this communication is happening because of the common trust factor between an identity provider and relying party, which is OpenID.

How Authentication is taking place?
Continuing with the same example of the blogger web site, the user hits the URL of and lands on the login page. There he enters his google credentials. Post that, request went to google for account verification. On successful verification by Google, the user is redirected back to the Blogger along with a token (we will discuss about the token shortly. But at this point, you can imagine it as a label which tells the blogger that this user is verified by google and blogger can rely on him). Hereon, Blogger trusts this token and initiates the session for the user.

OAuth is short for Open Authorization and is mainly used for access delegation via token-based authentication. Using this access delegation, application can access resources on the resource server on behalf of the user without the need of re-entering the credentials. This is achieved by using the tokens issued by an identity provider, with the user’s consent. 

Let’s understand this with an example, say you are going out of town and you want your friend Alen to stay and take care of your home. Of course, you have handover the keys to Alen. 

Which means Alen can enter the house and access the resources inside the house. In this analogy, home is the resource server, Alen is the client, door lock is the identity provider and I/house owner is the user. Makes sense?

Let’s change the thought process a bit. At present, until I’m back,  Alen is occupying home in my absence. Which means Alen is the owner of the house. Although it is for the time being but still Alen can be considered as an owner of the home. Such fable is termed as pseudo-authentication.

OpenID Connect
In order to implement a complete security solution, both OpenID and OAuth should go together. This togetherness is termed as OpenID Connect, wherein authentication is supported by OpenID and authorization is supported by OAuth2.

SAML is short for Security Markup Assertion Language and is an open standard for both authentication and authorization. It uses XML for all its transactions with a purpose of allowing identity providers to pass credentials to service providers. In most of the real-world scenarios, identity providers and service providers are totally separate entities. 

Now, for both to work on SSO mechanism, some sort of centralized user management is required and here comes in SAML assertions. There are three types of assertions:
  • Authentication: Tells that user is authenticated at what time and by using what method
  • Attribute: This is a piece of data which provides information about the user with some specific attributes
  • Authorization: Tells that user is granted or denied the access of any resource

Here is the summarized view taken from Jaime's blog about what each one of these does.

Token (or assertion) format
Year created
Current version
OpenID Connect
SAML 2.0
HTTP Redirect (GET) binding, SAML SOAP binding, HTTP POST binding, and others
Security Risks
OAuth 2.0 does not support signature, encryption, channel binding, or client verification.  Instead, it relies completely on TLS for confidentiality.
Identity providers have a log of OpenID logins, making a compromised account a bigger privacy breach
XML Signature Wrapping to impersonate any user
Best suited for
API authorization
Single sign-on for consumer apps
Single sign-on for enterprise
Note:  not well suited for mobile
Hope you enjoyed reading!

Wednesday, March 6, 2019

Traditional file helper won't work in .Net core

Prior to .Net Core, we use to handle file by passing various sort of parameters, like -in memory bytes, FileStream or file path and that use to work perfectly. 

But when it comes to .Net Core, passing a file path will not work exactly as ASP.Net MVC. In earlier versions, the path we supplied was considered as a physical path whereas in Core, same API is used to denote the virtual path. In other words, whatever path is provided will be appended with site URL. 

Now how to give physical path in .Net Core? 
No worries! Here comes the PhysicalFile helper for our rescue. To know more about it, here you go.

Keep learning!

Sunday, February 24, 2019

Confused with term Active Directory

Is On-premise Active Directory (Windows Active Directory) same as Azure Active Directory? In continuation to my previous blog post, this was one of another question asked to me.     

Well, although these both are active directories but there are few differences though. Let’s have a look at those:

  • Location - The most basic difference is, Windows AD is on-premise whereas Azure AD is cloud based.
  • Initial moto – As Azure AD is a cloud based, some web service support is associated, unlike unadorned AD
  • Protocols Used – Both the active directories use different protocols. As Azure AD uses SAML and oAuth whereas unadorned AD relies on NTLM and Kerberos for authentication and LDAP to query/modify
  • Platform support – When it comes to provide support on other platforms apart from Windows, it is nightmare with Windows AD and requires more time and effort. But the same thing can be executed very smoothly with Azure AD as it just needs a registration with any one of your Microsoft cloud application, i.e. o365, Microsoft Intune, Microsoft Azure, etc.
One can visit here to know more on Azure AD. Happy learning.

Monday, February 11, 2019

Windows Authentication & Forms-based Authentication

During my recent interaction with one of the development teams, I came across few queries. Hence, I decided to cover those general questions as part of my few upcoming blogs.
The very first question I received is, when should one go for Windows authentication and when one should go for Form-based authentication?
Now here one of the common response one can receive is – use Forms authentication whenever the user can supply username/password and go for Windows authentication whenever the user can use Windows Login System.
No doubt, this response is correct. But there are few more points which can elaborate it. Let’ have a look at those:
  • If user accounts are created in AD – go for Windows authentication using ActiveDirectoryMembershipProvider
  • If user accounts are created in database, i.e. SQL Server – go for Forms-based authentication using respective membership providers, i.e. SqlMembershipProvider
  • If user accounts are created in database whose direct member ship providers are not available – go for Forms-based authentication by writing custom provider
  • If Windows authentication can not be used with AD for any reason – go for Forms-based authentication
  • If you need more secure policies for password management - go for Windows authentication
  • If you want to use existing account management tools - go for Windows authentication        
I hope these few points will add some more to your knowledge. Happy learning.

Sunday, December 30, 2018

Bit on certificates

In continuation to my previous blog, here I'm writing something more on SSL. As we learnt that, one of the key components of SSL protocol is certificates. Certification is nothing but just a set of files which contains information like:
  • Owner of the certificate
  • Issuer of the certificate
  • Validity of the certificate, etc. 
Below is the sample certificate:

Before moving ahead, let’s have a look at the primary elements of certificates: 

  • Public Key:  This file with extension as .crt is installed on the server and is distributed freely to any client. 
  • Private Key: This file with extension .key is installed on the server and kept secret and secure. The file of SSL certificate contains information for encrypting data, it does not expire or have any details regarding organization or domain name. 
  • Signing Request:  This file with extension .csr is sent to certificate authority by an applicant while applying for certificate and is used to generate public key. The file contains all of the same information as the public key except for information about who has signed it.
A high-level picture - How communication happens?

Once handshaking is done, browser generates a random session key, which is used for connection hereon. This session key is sent to server in an encrypted form with the help of public key mentioned in the certificate. 

The best part is, only server has the private key to decrypt this random key. So, from that point on all the communications happening between browser and server are well secure.

How to verify that certificate is issued by valid authority?
Operating Systems typically have a list of trusted certificate authority. So, certificate sent by server is verified against this list.

What is CRL & what does it holds?
CRL stands for Certificate Revocation List. Every certificate issuer maintains a CRL which holds all the revoked certificates. Revoked certificates are those which are stolen and are blacklisted based on the certificate requester’s request.

Should we go with the paid certificate issuing authority?
Precisely yes as it is all about security and all the verification must go through a stringent verification process. A company that signs your certificate must first verify your right to the certificate in question. Then, they add stuff to the certificate that allows others to see that they indeed have verified your ownership to use this certificate. Which means, 

  • Issuing authorities check that the domain name in the certificate is actually owned by you and the people in charge of the domain approve the creation of this SSL. 
  • If there is information about your organization (i.e. company name) in the certificate, then this must also be verified.  People in charge of this company must approve the certificate.
Developer’s note - Does just adding an SSL certificate secures my web site?
Merely adding an SSL certificate to a site does not make the site secure.  Once SSL Certificate for the site is received, one needs to ensure that web pages that require security are only accessed over SSL (e.g. you need to link to them with https:// and not http:// links). One may also want to construct your site so that secure pages cannot be accessed via insecure links (e.g. http://).
Hope you like the briefing on certificates. Happy learning!

Monday, December 10, 2018

Is SSL and TLS same or different?

Yes, many people are using these terms interchangeably. But in today’s time, right term would be TLS. Well, understand what is this TLS and why do we really need it?

Most of us are already aware that HTTP is a plain text protocol which doesn’t have its own transport security mechanisms. In other words, HTTP is a protocol which sends data to a server and gets a response without any built-in feature or mechanism to protect data packet against tampering.

To protect our packet which is travelling through HTTP, some sort of secure tunneling is required and that secure tunneling is provided by a protocol called TLS a.k.a. SSL. Here HTTP and TLS comes together.

Usually people associate SSL/TLS with encryption, but that is not the only feature SSL provides. There are few more features as:

Server Authentication – It makes sure that communication with the right server is made
Veracity Protection – It promotes integrity and makes sure that none in between is reading our data
Confidentiality – It makes sure that none should know what data is being transmitted

Associating above features with HTTP makes HTTPs more reliable and authentic. Now question may be, how to achieve this or how to implement this SSL. Here comes in the requirement of certificates. Do wait for my next article to know more on certificates.

Happy learning.

Friday, September 14, 2018

Microsoft announced ASP.NET Core 2.2

In yesterday’s .Net conference, Microsoft announced ASP.NET Core 2.2 as part of .Net Core 2.2 Preview 2 SDK and Visual Studio 2017 15.9 Preview 2. List of new features looks very interesting. Let's have a gist of those:
  • Template updates: This release includes Bootstrap 4 support in ASP.NET Core Web Project templates as well as in scaffold and is the default version for UI, which gives completely new look.
  • Supports Angular 6 for SPA based templates.
  • Web API related changes are the major improvements in this release and contributes towards much easier and much better Web APIs.
  • HTTP/2 support is added for Kestral.
  • lIIS in-process hosting model is added for IIS for much better performance and reliability.
  • Health checks framework is integrated now to monitor health of APIs and apps.Using this we can make sure that our apps and APIs are live and ready for traffic prone situations.
  • New routing system Endpoint routing was brought in, which takes care of several routing problems and performance issues. 
  • SignalR Java client is added.  

Monday, September 10, 2018

Web API Resource URI construction Practices

Main focus of this article would be on how to make Web API more understandable to the consumers from Resource URI construction point.

In Web API, each resource will have unique identifier. So, one should be very careful while constructing these URIs. Here are the few very good practices one should go for:

URI should belong to NOUN rather than ACTIONS.
URI example
Is preferred?

Using GET

Fetch employee with a given ID using GET



Filter criteria

Should Nouns be Pluralize or not?
It is up to you whether you want to go for pluralize nouns or not. But whatever decision you are making it should be consistent throughout the controllers and actions.

IDs should be integer or string? 
One point to remember here is, resource URI construction has nothing to do with the way data is stored at backend. REST API has nothing to do with data storage mechanisms. In other words, if backend is changing over time, URI must not change. 

For example, Today you are using SQL server database with auto incremented integer key as an ID. Now, what if I suddenly planned to move to Mongo DB. Will I go ahead and change my URIs to accommodate ID as a string? Certainly not. 

Best solution for this – GUID. GUID can be used as a primary key in any database, which will provide more flexibility while changing the backend database keeping the resource URI intact. GUID will also help us to hide underlying technology.

Please note, all the points mentioned above are just the guidelines and by following these we can end up with good URI design.

Monday, September 3, 2018

Generating documentation for Web API 2.0

In my previous article, we got the gist of Web API but we didn’t do anything on documentation part. So, in this article we will cover the documentation of our Wep API which will help the users using Swagger.

What is Swagger?
Swagger is a standard which is used to define the API, so that endpoints can be found and discovered easily with the help of small documentation along with the user interface. If it is clear that what API is doing, one can easily consume these APIs. It is similar to WSDL for Web Services.
How to get Swagger?
Swagger is an open source library with a name SwashBuckle and can be taken by any means of importing packages. Let’s have a look on how to get it from Nuget:

What code changes are required?
First of all, we have to go and register the service for swagger as:
public void ConfigureServices(IServiceCollection services)
{ services.AddMvc(); services.AddSwaggerGen(options=> {
options.SwaggerDoc("Version 1", new Swashbuckle.AspNetCore.Swagger.Info { Title = "Conference Planner", Description = "This holds methods to perform CRUD operation using in-memory database." });
services.AddDbContext<ApplicationDbContext>(context => { context.UseInMemoryDatabase("ConferencePlanner"); });
Next, we must do configuration related changes along with enabling the user interface for us. This can be done as:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
if (env.IsDevelopment())
{ app.UseDeveloperExceptionPage();
app.UseSwaggerUI(swag =>
swag.SwaggerEndpoint("/swagger/version1/swagger.json", "Conference Planner APIs");
We are almost there. Now quickly build and run the application with an URL as http://localhost:3394/swagger/Version1/swagger.json. Please note, for you it can be different port number. Once the page is loaded, you can see the generated JSON as:

Above JSON contains all the information which is required for any consumer.

Last but not the least, the UI part. To view the UI, URL has to be changed slightly as http://localhost:3394/swagger/

And we are done with SwashBuckle, which is an implementation of Swagger. Happy learning.