With growing usage of IT in day to day life, there are chances of misusing any available online services. According to economics times Over 15,700 Indian websites were reported hacked this year up to November 2018. So with the given dynamics lets see what all options we have to protect our resources. But before jumping to solutions and type of protection available let's get familiar with some common terminologies. Let's get started...
Relying Party: A relying party (RP) is a computer term used to refer to a server providing access to a secure software application. Or we may say RP is a website or other entity on the Internet that uses an identity provider to authenticate a user who wants to log in.
Claims: Claims contains the information that we passed to the application like Name, Age, etc post authentication.
Identity : Are you the right person trying to access the application. For example, whenever you enter the office premise you need to show your batch to enter the premise.
Identity Provider (IDP): Is the term for a server that authenticates a user (the server is connected to some account SQL database, AD, etc.). In India, Aadhaar is used as IDP to confirm our Identity.
Authentication Vs Authorization: Authentication verifies you are who you say you are whereas Authorization decides if you have the permission to access a resource. Authorization occurs post authentication is successful.
Only an IDP can perform user authentication
Service Provider: SP is an entity which is providing service. As we can see in below example here we are trying to protect an SP which has a trust established with an IDP. So whenever someone tries to access the service provided by Service provider they need to be authenticated against the IDP and post successful authentication the user can the resource. In a real-world example, we can think of SP as google drive and IDP as google. So to access google drive you need to log in with your Google credentials first.
Federation Provider: FP is often used for a server that receives a SAML Token from another server. And then forwards it to the next Relying Party. For example, In case if you have forgotten your office Id card in home and the security personal stops you on the gate. Instead of asking you puzzles to confirm your Identity he federates/ redirects you to the main office to get temporary Id card for the day.
Identity And Access Management: IAM refers to a framework of policies and technologies for ensuring that the proper people in an enterprise have the appropriate access to technology resources. Also called identity management (IdM), IAM systems fall under the overarching umbrella of IT security.
In the real world, the best example is your Aadhar/ Green Card. When you present your Aadhar/ Green Card to the bank to prove that you are you, the bank (service provider) is trusting that the Aadhaar/ Green Card(identity provider) has properly vetted you with birth certificates, social security cards, or other identity information. Because of this trust, or federation, you don't have to carry all of these documents with you everywhere and prove to every single person that you are you. They trust the Aadhaar/ Green Card to have taken the appropriate steps to prove your identity.
Now since we have got some basic clarity on the security terminologies, let deep dive into more real-world challenges and the solutions available to overcome those challenges.
What is the basic component of IAM and what IAM system should include?
Basic components of IAM:
- How the individuals are identified in a system?
- How roles are identified in a system and how do we provide the roles to the users?
- How we will manage the roles of users?
- Assigning levels of access to individuals or groups of individuals
- Protecting sensitive data like PCI(credit cards info) within the system and securing the system itself.
IAM system should include all the necessary controls and tools to capture and record the above features.
What is Roles Based Management?
RBA helps us to manage the necessary permission for an authenticated user. Example: Using our employee office Id cards we can easily enter most of the floors but we can't enter server rooms. In case if you are a developer and you have access to server rooms, I think it's time to talk to your security team to strengthen the RBA policies :-)
What is Single Sign-On (SSO)?
Imagine our condition if Google starts asking us to punch in our credentials every time we use any of their services. Our condition will be something like below. We surely don't want to ask users for credentials every time they use any of our services. Even if we own 10 applications, we should authenticate users only once and let them use all 10 applications.
SSO is a user authentication service that allows a user to enter his credentials once and be able to access multiple applications. For example, if we want to access google drive or google album or google contacts, we need to login into our google account once and we can access all of them without entering the password every time. Please refer below image for better understanding.
What is SAML and how it works?
Now we are clear that we should ask users to enter their credentials only once even if they want to access our multiple applications. But how will we know it is the same user? For example, we have 2 application A and B and user enter credential to access application A and now wants to access application B. We need to have a mechanism to let application B bypass authentication and handle validation internally without popping up the login screen to the user.
SAML stands for Security Assertion Markup Language. It is an open standard that allows Identity Provider (IDP) to pass authorization credentials to service providers (SP).
SAML Provider is a system that helps a user access a service they need. There are primary 2 types of SAML providers:
- Service Provider: A service provider needs authentication from the IDP to grant authorization to the user.
- Identity Provider: An identity provider performs the authentication that the end user is who they say they are and sends that data to the service provider along with the user’s access rights for the service.
SAML works by passing information about users, logins, and attributes between the identity provider and service providers. Each user logs in once to Single Sign-On with the identity provider, and then the identity provider can pass SAML attributes to the service provider when the user attempts to access those services. The service provider requests the authorization and authentication from the identity provider. Since both of those systems speak the same language – SAML – the user only needs to log in once.
Each identity provider and service provider need to agree upon the configuration for SAML. Both ends need to have the exact configuration for the SAML authentication to work.
What is OAuth and how it works?
OAuth(Open Authorization) is an open standard for token-based authentication and authorization on the internet. An end user talks to their identity provider, and the identity provider generates a cryptographically signed token which it hands off to the application to authenticate the user. The application trusts the identity provider. As long as that trust relationship works with the signed assertion, you’re good to go. The diagram below shows how this works.
Below is an example of OAuth:
There are multiple features provided by OAuth like:
- Scopes and Consent
- Actors
- Clients
- Tokens
- Authorization Server
- Flows
Please refer Blog for more info.
When we had SAML, why we need OAuth?
SAML is basically a session cookie in your browser that gives you access to web apps. It’s limited in the kinds of device profiles and scenarios you might want to do outside of a web browser. Now we have modern web and native application development platforms. There are Single Page Applications (SPAs) like Gmail/Google Inbox, Facebook, and Twitter. They have different behaviors than your traditional web application because they make AJAX (background HTTP calls) to APIs. Mobile phones make API calls too, as do TVs, gaming consoles, and IoT devices. SAML SSO isn’t particularly good at any of this.
What is Service Provider (SP) initiated Single Sign-On (SSO) Flow?
When the service provider generates an request which is send to Identity provider as the first step in the federation process and the IDP responds with a SAML response we call this SP initiated flow. Refer below Image
Processing steps:
- The user requests access to a protected SP resource. The request is redirected to the federation server to handle authentication.
- The federation server sends an HTML form back to the browser with a SAML request for authentication from the IdP. The HTML form is automatically posted to the IdP’s SSO service.
- If the user is not already logged on to the IdP site or if re-authentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on.
- Additional information about the user may be retrieved from the user data store for inclusion in the SAML response. (These attributes are predetermined as part of the federation agreement between the IdP and the SP)
- The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP. NOTE: SAML specifications require that POST responses be digitally signed.
- (Not shown) If the signature and assertion are valid, the SP establishes a session for the user and redirects the browser to the target resource.
What is Identity Provider (IDP) initiated Single Sign-On (SSO) Flow?
When the federation process is initiated by the Identity provider by sending an SAML response to the service provider. Refer below Image
Processing steps:
- A user has logged on to the IdP.
- The user requests access to a protected SP resource. The user is not logged on to the SP site.
- Optionally, the IdP retrieves attributes from the user data store.
- The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.
Let us look at real world example to understand above
SP Initiated SSO
Monika the user: "Hey Hari, show me your project report"
Hari the SP: "Hey, I'm not sure who you are yet. We have a process here so you go get yourself verified with Nithya the IdP first. I trust her."
Nithya the IdP: "I see Hari sent you here. Please give me your credentials."
Monika the user: "Hi I'm Monika. Here are my credentials."
Nithya the IdP: "Hi Monika. Looks like you a genuine user"
Nithya the IdP: "Hey Hari. Monika is authenticated user and here's some additional information about her. You do whatever you want from here."
Hari the SP: "Ok cool Nithya. Monika, Here you go!"
IDP initiated SSO
Monika the user: "Hey Nithya. I want to view Hari's project details. But Security is tight over there."
Nithya the IdP: "Hey Hari. I trust Monika. She is genuine user and here's some additional information about her. You do whatever you want from here."
Hari the SP: "Ok cool Nithya. Monika, Here you go!"
Reference:
Top comments (1)
Very thoroughly documented Jai. truly reflects the hard work you have spent in understanding this really complex space.