I hate talking about technical jargon, but it is important to understand some of the terms which will be used frequently, though I am not an expert by any means but i’ll try my best to help you understand these jargons in simple terms.

Identity Provider (IdP) -:

• Identity Provider or IdP for short is an authority system which provides the identity of the user to the relying parties.
• Take an example of DMV which verifies your 6 points id and then issues you a driving license, now you can present this licenses as your identity to other places like at Airport security.
  
  
• In this example, Airport security is a service provider which is relying on DMV as the identity provider.

Service Provider (SP)-:

• Service Provider (SP) is also called Relying Party (RP) in Single Sign On world. It is usually an application or service which relies on the Identity provider to authenticate the user and provide its service to him/her.
  
  
• In our example above, Airport Service is a service provider (or relying party) and DMV is an Identity provider (IdP).

Let us understand them better with one more example – This weekend I went to a bar near me to have couple of IPAs:), they asked me for a proof which shows me as 21 years or older, I presented my driving license, here DMV is my identity provider and this bar is the relying party (or Service provider) as it is relying on DMV to provide me the service (beer as a service…. yeah….).

Security Assertion Markup Language (SAML)-:

• When two entities talk to each other, they need to agree to talk in a predetermined language, right? Let say if the president of the United States of America is talking to the Prime Minister of India about negotiating a deal, how would they understand each other as they speak different languages?
• Ideally, they would have a translator who understands both languages and then help these leaders with the translation in their own language, so they can make informed decisions.
• Similarly, when Okta and Google need to talk to each other where Okta will say to Google ‘Hey Google, I confirm, Goldy is our employee, let him login to Google Workspace’, this interaction takes place in the language or standard they both understand, this language is called “Security Assertion Markup Language” or SAML for short.
• As per Wikipedia -: Security Assertion Markup Language (SAML, pronounced SAM-el) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
  

User Attributes-:

• Attributes are like properties of a user, which helps us gain more information about a user, for example, if a user’s job title is CEO, that tells that this user is  an executive, or if the user’s department = sales, that tells us that this user works in the sales department.
• There can be multiple attributes assigned to a user (like first name, last name, email, phone, department, employee ID etc).
• You might also create custom attributes which are so specific to your business, for example if your company provides uniform to employees,  you might want to know the shirt size of your employees, and would create an attribute like shirt_Size which will then be filled up based on respective user’s shirt size like S, M, L, XL etc.
• These attributes help us make dynamic rules as we will see later in the post, for e.g create a rule in Okta which says if the user.status = ‘full time employee’, then assign Google Workspace application to these users.

Attribute Transformation-:

• Sometime you would see scenarios where you would need to change the attribute’s value on the fly, let me give you an example, our domain name is @olddomain.com in Okta, but in Google Workspace our domain name is @newdomain.com.
• Now, Google expects that Okta will refer to user@newdomain.com in all the interactions as Google does not have any information about user@olddomain.com.
• In this specific case, we can create an attribute transformation rule in Okta saying, if the user is trying to access Google Workspace, change their email address on the fly from user@olddomain.com TO user@newdomain.com, this is called ‘Attribute Transformation’, geeky way of saying this would be ‘Send transformed attribute in the SAML response’.
• This way, Okta can send the user attribute value which is expected by the target application without changing this user’s attribute in Okta or for other applications assigned to this user in Okta.

Single Sign On (SSO)-:

• An authentication method where a user can login to multiple applications with just one set of credentials is called Single Sign On (SSO).
• This one set of credentials belong to user’s identity provider (for e.g Okta in our use case here), and then behind the scenes this identity provider integrates with other applications or service providers (e.g Google Workspace, Salesforce etc).These applications rely on Identity provider for user authentication instead of asking users to provide user id and password.

RelayState

• You can think of the relayState as the first destination where you will land after your IdP authenticates you to the service provider.
  
• For example, after Okta authenticates you to Google, whether you would land at Gmail, or Google Drive or Google Sites, it really depends on what you have set up in the relayState parameter of the SAML response.
  
• This might be helpful to know, especially for cases where you want your users to land at a specific Google service after authenticating themselves via Okta.

Network Masking-:

• This is specific to Google Cloud Identity (or Google Workspace) where you can restrict the scope of Single Sign On (SSO) to an IP range.
• For example, if you put an IP range in Google’s network mask while setting up SSO, Google will only redirect users to your IdP if they login from an IP address that belongs to this IP range, other users will be required to login via their Google email address and password as usual.

Classless inter-domain routing (CIDR)-:

• When you configure Networking Mask in Google while setting up SSO, it does not take the IP addresses, rather a CIDR.
• CIDR is a flexible way to define how many bits of an IP address belong to the network (network ID) vs host (e.g host ID), so if you take C class IP4 (192.168.12.12) as an example here and put /32 to it (e.g 192.168.12.12/32), then it means 32 bits (note /32) are the network id which will result in just one IP address.
• We will use this when setting up Okta SSO with Google Workspace, so we can restrict SSO scope to only one IP address for testing before enabling it to all users in our company.

Session Timeout-:

• When you start interacting with an application, it would ask you to authenticate for the first time, however to provide you rich experience, it will create a session which will uniquely identify you, this helps avoid a situation where it needs to ask you to authenticate every time you do interaction with that application.
• You would find different applications with their own default session timeout, for e.g Google Workspace (Gmail, Drive etc) has a default session timeout length of 14 days, which means once you authenticate yourself, then you would not need to authenticate for 14 days (except some scenarios like IP, location, reset cookies etc changes or Google finds something suspicious).
• Some applications provide a way to change default session timeout and have your own custom setting there (like Google Workspace), which means if you change the default session timeout to 2 hours, then users will need to re-authenticate themselves every 2 hours.

SLO

• Single Logout (SLO) -: When your Identity provider (e.g Okta) authenticates you to the service provider (e.g Google Workspace), a session is created. Now if you logout from Okta, your session is still active with Google Workspace, and if you logout from Google Workspace, your session is still active with Okta.
  
• Single Logout (SLO) is a way to kill all the active sessions for both (Identity provider and Service provider).