Transcript for:
Overview of Okta Identity Management Course

hello viewer welcome to mind magics i am emma and i'm here with okta's entire course video okta is considered the world's number one identity as a service platform allowing enterprises to add authentication and authorization to the applications this video will teach you everything about the octa and its usage in the real time industry if you are new to the mind magix youtube channel please subscribe to get full length career courses tutorials and tech videos first we will start with understanding identity access management and then look at secure authentication markup language followed by the open id connect once we understand these fundamentals we shall walk through the advanced concepts of octa like administrative ui and opta integration network in the end we will explore octa user groups and applications without any further delay let's get started with the first topic today we are you know going to cover what is identity and access management so we are going to have an overview of what i am is all about the identity and access management domain uh like you know why do we require i am what is the need of i am and you know we will understand the basics of identity and access management before we jump onto you know our main product of i am that is optimum so uh this particular domain that is identity and access management that has been segregated into two different categories one is identity management and the other is access management as the name suggests so looking at the information what we have on the screen right so you could see that you know as an end user uh whenever you join an organization there is a requirement of doing identity management as you have many downstream applications like your active directory ldap app any other application like workday sales and you know you require to do a single sign-on to these particular application so that's why uh that's where access management comes into existence and that's where you know you require both identity management as well as access management in an organization so that you know you you give right level of access to the right people for the right purpose so you know talking about the access management it's basically supporting the authentication mechanisms including single sign-on multi-factor authentication federation and the password management so uh like you know anything on the single sign on like that is like you know you you you can just log in once uh using your credentials and then you know once the session is created with your browser you don't have to log in again and again that's your single sign-on and then the other is multi-factor authentication like you know just adding a layer of security on top of your first factor authentication so you enter your credentials and then you know you need to again authenticate yourself with one of the knowledge like you know with one of the things like something you have something you possess or something you know and you know then password management basically is the concept that you know you need to manage your passwords effectively uh like you know you you don't have to uh you have to keep changing your passwords within the regular interval of time and stuff like that so that's basically your access management like you know mainly dealing with the authentication concepts that's where you know the access management comes into existence uh then you know we although like i just mentioned that you know i am domain that is identity and access management domain it just comprises of identity and access management but there are you know other domains as well i mean not domits i would say but other uh areas as well within this domain where you know we require uh to work on so one of them is access governance so it's basically you know the policy based activities enabling the definition enforcement review and auditing of iam functions and policy compliance so as you know uh as the name governance suggests so basically it's going to go on whatever is happening inside the organization so it's basically going to uh govern all the access that the users are going to have so you know you you as an im developer would be writing policies and your system would actually be you know governing all the access-based policies or you know anything whatever their whatever access has been given to the end users uh that you know why do they require it or what like when do they require it again for what purpose it was so all of this you know reviewing and auditing of buying functions is being done under access governance uh then we then comes the identity management so it's basically you know in simple words if i have to explain it's basically the life cycle of the user so when a user joins an organization maybe the so that's called as a joiner when the you know the user moves within the organization you know maybe the role of the user is changing from one designation to another designation that's like a mover and then finally the user leaves the organization you know so that's like a lever so basically you know administering or you know looking at all of these information like when a producer is joining or moving or leaving that all runs under identity management uh then we have what privileged access management so basically privileged access management is somewhat like access management but this time in this particular topic we cover the privileged accounts which we have in an organization so there could be a possibility that you know we have privileged accounts like you know special accounts being created within an organization for special purposes uh generally we call these accounts at service accounts uh but you know and these accounts are like you know uh privilege with a lot of permissions like when we talk about our accounts or you know the other users accounts uh generally in an organization like you know if you are a normal user or an or an employee your account is not loaded with a lot of privileges you know you have simple privileges you don't have admin rights and stuff like that but when we talk about privileged accounts like you know these shared accounts or service account these are being you know loaded with high privileges so you know these needs to be taken care of you know uh with a lot of uh we need to care take care of these accounts because you know anything which happens with these accounts could you know do a lot of data or a security breach for an organization so that's why that's what this uh area of you know topic helps us to achieve and then finally we have data security and analytics and it's you know the ability to manage the unstructured data providing the data classification identification and user interactive to support data security program so whatever data we are going to secure right so all of that data needs to be analyzed as well and that's what comes under data security and analytics okay so now you know we would like to understand why do we need i am like you know we just uh we just gone through like what is identity and access management but now we need to understand why do we need i am so identity and access management is a critical part of men of an enterprise security plan as it is linked to the security and productivity of organization in today's digitally enabled economy compromise user credentials often serve as an entry point into organization's network and its information assets enterprises use identity management to safeguard their information assets against the rising threats of ransomware criminal hacking phishing and other malware attacks so you know basically like you know to sum up these two points i need i'm saying like you know i would say that basically the iam is required to you know it's a critical part for any organization the reason being because you know more and more we are going into this you know into this id world we will see that you know more and more digitalization is happening if you would have noticed like you know before prove it also like you know our country was doing very well in the digitalization but like you know the dependency on digitalization has increased once this move it has occurred because like you know everyone is working from home everyone like you know more and more devices more and more working on laptops computers mobiles and stuff like that so we are kind of you know getting digitalized you know as we are progressing in our uh as we are progressing so more and more we are getting digitalized so there is a chance you know that the more vulnerable we are you know towards cyber attacks or you know phishing or hacking and stuff like that because more people are going to use the digital devices and hackers are going to target those weak audiences who does not have the awareness of who does not have the knowledge to you know how to use the digital assets or you know if the data is not being secured so you know there is a higher chance that that data is going to be breached by the hackers so that's why we require i because i am is kind of ensuring that you know what level of access this should be given to what people for what purpose and at what time so you know like you know once the acts maybe you know we are working in a project and i have you know completed that project now i might not be requiring the taxes but still if i have that taxes i could do anything with that you know access because now i have completed my project so i'm not responsible for it but still if i'm having the access i get to go ahead and do anything right so so that's where you know i am comes into existence it will you know just remove my access once my project is completed or if i have uh left the organization at that point of my at that point of time my access is going to be revoked so you know i don't have to worry that i mean like the organization doesn't have to worry that okay you know this access is there or you know what will happen if this is not going to be removed and stuff like that so that's why we require i am in many organizations users sometimes have more access privileges than necessary a robust time system can add an important layer of protection by ensuring a consistent application of user access rules and policies across an organization so i just mentioned this point right now so you know uh like whenever we are working for an organization right so most of the organizations they don't give you know admin privileges to your system as well like you know even if you have to install something on your on your device on your laptops given by the company you need to reach out to the it team and they are you know going to install stuff like that so whatever you know uh and the reason behind it is because like you know they want to give minimum privilege to the end user because if you have an admin guide summary system you have companies data on your on your laptop now you can you know install anything do have go ahead and do anything with your uh with your you know uh with company's data so that's why they you know kind of put that the policy on the laptop that okay if you need access or you know if you require an application to be installed raise an id ticket and you know then do it but for certain organizations where we do not have this restriction like you know an end user has anything uh has a the admin privileges and stuff like that so they can you know do anything on the system i'm not saying that they will do it but the thing is like you know everyone in the organization doesn't work ethically so you know there are unethical people also who could take advantage of such situations and that's where you know a system or a software is required you know which actually helps you to um make sure that you know even for the unethical people uh you know data or data of an organization is not getting these because like data for an organization the data is the most important part like if data is getting reached then ransomware attacks and we know many other criminals in cyber attacks whenever the data is based the organizations are ready to pay as much as the hackers or you know the other people who want the other side of the party wants so that that suggests like you know how much important the data for an organization is so you know we they cannot just simply compromise their data with the with the you know with not being implementing im in their organization so that's why we require im identity and access management can enhance business productivity the system central management capabilities can reduce the complexity and the cost of safeguarding user credentials and access at the same time identity management systems enable workers to be more productive in a variety of environment when they are working from home the office or on the road so that's what like you know when we are working from home or you know when we are uh like working from outside our office location so that's where you know we need to make sure that you know because now we are not on the office suiteman also so there is one layer of network security which you know which can block data or allow because if you are working on your own wi-fi anything can happen so at that point of time we require im systems to be enabled so that you know uh like there is a tracking activity or a governing activity going on that you know what is happening on our systems what is what the user is doing is he doing something right or wrong see you like this should be done only on the enterprise level at the enterprise level i mean um because like you know if you're doing something on your own laptop that's fine like you can do anything but that you don't have your organization's data or anything else so that's fine but like if you're doing something on organizations laptop or you know organizations device then it's kind of you know security or a database or an organization that's where that should not happen so that's where this iam is required uh now the next thing is like how this i am works so in years past a typical identity management comprised of four basic elements which included a directory of the personal data of the system used to define the individual users a set of tools for adding modifying and deleting the data a system that regulates user access and an auditing in a reporting system so we you know like in past and like if i talk about like how the sign used to work 15 years back so it basically comprised of four different elements one was that you know a directory or you could say an excel file or anything like where the user information was stored then a set of tools for adding modifying or deleting those users maybe new users are getting added so we need to add maybe some users are getting going so we need to remove a system that regulates the user access may be the enforcement of security policies and accessibility and finally an auditing and a reporting tool so these four actually comprise of our im part regulating user access has traditionally involved a number of authentication methods for verifying the identity of a user including password digital certificates token and smart cards hardware tokens and credit card size the smart card served as one component in two factors indication which combines something you know something you have to verify your identity uh so that's what like you know our regulating user access is very uh you know it was involved with a lot of authentication methods for verifying the identity of a user which included our password or some certificates or maybe you know multi-factor authentication and uh in today's complex compute environment along with the height and security threat a strong username and password doesn't cut it anymore today identity management system often incorporates elements of biometrics machine learning and artificial intelligence and respect risk based authentication so basically you know as in like right now we are progressing now so as and how we are progressing so you know like there is a more complexity coming into you know existence so now in this complex environment we need to hide in the security threat so just having a strong username and password doesn't surprise because you know there are more efficient work hackers now like you know they are more intelligent now to intellectual to actually crack your code or your password so that's why you know it's it's more you know now the identity management is often coming with some more a complex way of getting used integrated that is bio matrix like because you know written a display or you know maybe fingerprints is something not easy to easy to crack for an hacker or you know maybe bringing in machine learning and artificial intelligence or maybe you know risk-based authentication so you know all of this actually adds the layer of security on top of your username and password so even like you know if your one person your password is is being compromised so you still you know have other practice with you which will not allow the hacker to get into your account so we need to make sure that you know these uh we are you know following these im standards at the user level recent user authentication methods are help helping to better protect identities so you know for example the popularity of facial recognition and iphones has familiarized many people with their fingerprints as an authentication method newer windows or 10 computer software fingers offers fingerprint sensors or iris scanning for biometric user authentication so now you would be seeing like like this facial recognition was actually the concept you know which came from apple and now you know you will see that in all the phones and all the mobiles that are coming in the market they have the spatial recognition and now you know even in the laptops you'll see that you have the fingerprint scanner coming up in from windows 10 and maybe macbooks or you know somewhere they are also scanning your iris to get into your system to do the authentication so that's how we are progressing so that's how our iron works so yeah uh like as i mentioned before like what is identity management it's basically you know the organizational process for identifying authentic authenticating and authorizing individual or a group of people to have access to the application systems or networks by associating user rights in restriction with established identities idm is the task of controlling information about users on computers such information includes information that authenticates the identity of a user and information that describes data and actions they are authorized to access and perform it includes the management of the descriptive information about the user and how and by whom that information can be accessed and modified in addition to the users manager entities typically include hardware and network resources and even applications so basically you know it's it's just talking about that you know it's basically the organizational process of identifying authenticating and authorizing so you know these three are the terminologies in im uh market or in im world uh which we often use that is identifying authenticating and authorizing so you know we need to understand what this identifying is so basically any user coming into the coming or you know any any any employer or any end user coming into to access certain things we need to identify whether it's the right user or not like you know maybe you are trying to access something of the companies like and you have just entered your email right now and you know you're maybe entering your gmail id so at that point of time it has to be identified that this is the wrong user id we are using then authenticating like you know by your username and password or you know your multifactor and then finally authorizing that you know authorization is like what level of access you have you may be getting into the system but you are not a super admin or you know you do not have admin privileges or you have certain privileges according to your role defined in your organization so basically you know managing this uh efficiently this you know identification authentication and authorization all of that comes under identity management so you know if i have to just sum up what is identity management so it's basically like you know you as an employee you join an organization the hr intensive details in the employee details and finally that goes into the active directory active directory is your application over here so you know all of this has to be managed efficiently like you know there could not be individuals you know setting it to add your data when you're joining if you're moving then you know you again have to do it manually then you know like go to the active directory manually all of this process has to be automated and automation of hold of this process is known as identity management so you know i have got certain more uh diagrams to show you that you know like if you there is a system there is a person in an organization all of these are grouped under as entities then you know there are different identities so these identities actually correspond to these entities which could be a system personal organization and you know these identities are going to have different names and attributes you know these attributes and needs are actually going to help you understand like you know what who is the exact user trying to access what so yeah that's what like well uh last topic for the day is like you know just to understand the main concepts of im so first of the you know terminologies which we have under imr centralized access management so basically you know handling user authentication and account management at a central system so you know uh simple example is like you have got easy in your home and then you have got a centralized ac in your office so that's exactly the same thing if you're doing it for a smaller thing you know it's just access management but if you're you know centrally if you centrically want to manage it for the whole organization so that's your centralized access management user provisioning now you know whenever you hear this word provisioning just try to remember that it's you know creation or you know managing the users so that's what like just uh whenever it could be user provisioning account provisioning uh application provisioning data provisioning i mean sorry i did identity provisioning so whatever you find you know with the word provisioning just remember that you know it's creating and managing so like all or just remember it's the creation so whenever something is getting created or added that's your provisioning so basically creating and managing user accounts or identity information within the system then single sign-on i just mentioned when we started this session it's basically you know authentic authenticating the users one and allowing them to access to be multiple applications so you know you don't have to log in again and again you just have to you know remember your one password and credentials and with those username and password you will be able to you know enter or access all the applications which have been integrated through sso and then multi-factor of the indication is again you know adding a layer of security on top of your main security layer so that's good that could be a password sms fingerprint anything adaptive authentication is something you know authenticating used by challenging with multiple authentication steps based on the user's list profile so basically you know if it's a high risk profile like you know if there is a profile which is having high risk so at every point you know maybe a user is being authenticated like you know uh they'll have to prove their identity again and again if it's a low risk profile they might not be allowed to you know thinking that they might be just asked to authenticate once and then you know they can access so high risk profiles are going to definitely have a high risk roles attached to them and that's why they require to you know authenticate again and again and that's what this adaptive authentication is all about identity federation is authentication users existing in an external identity provider so we are going to you know discuss this topic of federation later on but just think like you know when whenever we have an external idp or you know some other organization coming into existence that's where you know the federation concept will always come into existence and then we'll have this reporting that is iron systems provide reports that helps organizations prove compliance with regulations identify potential security risk and improve their imm and security processes so basically the you know analytics and data whatever the im comes up with we need to report them and analyze them and that's what you know that helps us to efficiently improve our immune security process so yeah so that's what uh the im is all about like you know just an overview of what i am identity and access management is so basically you know saml is one of the single sign-on protocol and you know there are different standard single sign-on protocols what we have in identity and access management doing so basically what happens is that uh we mentioned that you know we have understood what single sign-on is so single sign-on is that you you know just log in once to your uh browser or you know using oct or any other access management tool and then if your application is integrated with that product you will be able to access all the other applications without having to enter your credentials again and again so there are some standard protocols which actually you know uh helps us to achieve this uh process or mechanism and one of them is saml uh other we have is oidc and then octa comes up with its own you know protocol which is secure web authentication it's not a standard uh single sign-on protocol but it's like a workaround for you know uh the sso protocol where the federation is not possible and then you know you have got some api templates protocols which is your ws so we will see you know what saml is before we move on to that so you know as i mentioned that uh like you'll have your system then you'll have octa application which is on cloud and then you will be you know getting into the octa application using https you know you you will go to your browser you will hit the https link of octa and then within octa you will see that you know there are many applications integrated so these applications are actually going to be integrated either through saml oitc or secure web authentication and then you as an end user can actually you know go ahead and directly uh open i mean open an application if you have [Music] created a session with doctor then you'll be able to get into these applications without having to enter your credentials again and again so moving on to this tamil now uh there are some basic you know terminologies or terms what we have in family and you know it's very necessary for us to understand each and every terminology because that's how like you know once you understand saml that's how you'll be communicating in these terms so you know we need to understand the flow we need to understand the terminologies what we have in the salmon and then you will see and i'll mention these terms you know while showing you a demo of what saml is all about so basically if i have to talk about salmon then we have a sp which is a service provider so basically it is the entity providing the service typically in the form of an application now easy example would be again uh i remember giving an example of somato and google so in that scenario your zomato is the service provider i mean as the name suggests so whichever application is going to be providing the service that becomes your service provider and whosoever would be authenticating the user the end user who is trying to get into the application would become your identity provider so an identity provider is the entity providing the identities including the ability to authenticate a user now the identity provider in order to authenticate a user that identity has to have the user right like it's not necessary that the user should be created in that particular id identity provider but still that identity providers should have the information okay whether this user exists or not that identity provider can have that user either coming from active directory ldap directory application users and you know maybe many other sources but like or maybe in its own like you know the user created in its own environment but the identity provider has to have that identity in order to authenticate the user then only you have the ability to authenticate the user the identity provider typically contains the user profile some additional information about the user such as the first name last name job code phone number address and so on and why do we require this because see uh if i just have to you know authenticate a user based on his first name and last name so there are many people in this you know world having same first name last name and you know many other attributes for certain people are saved so now there could be a conflict of you know identity because you know there has to be at least one unique attribute for every user which helps us to identify that you know this is the right user trying to log into the system uh maybe you know there are two with four girls or you know there are maybe two other people with the same name having same age same agenda same you know profile same location but at least one of their attribute has to be different right like which will actually you know make them unique or identify that you know these two individuals are different so that's why you know uh like you know identity provider contains a lot of user attributes uh which could be you know different profile attributes and depending on the application some service providers may require a very simple profile while others may require a richer set of user data so as i mentioned that you know basically what is going to happen is that this identity provider and the service provider is going to you know create a trust between them these let's treat them as two different parties all right entities and you know they need to have trust between each other until unless they do these two identity entities don't trust each other you know there is no point of single sign because like you know if identity provider doesn't trust service providers service provider doesn't trust the identity provider then you know there cannot be any exchange of metadata i mean there cannot be any exchange of information between these two uh entities and if there is no exchange then single sign-on cannot be achieved so basically we create a trust between these two entities and now once the trust is created so service provider says to the identity provider okay you give me these these information for a user whoever you are going to authenticate identity provider because there is a trust trust with service provider so identity provider also provides that information to the service provider so it's like you know two-way communication between these two entities and whatever information is required from the service provider on successful authentication or unsuccessful authentication uh the identity provider actually provides that information to the service provider now i've just mentioned that you know identity provider is the one authenticating the users service provider is the one you're trying to get into and basically simple terms i have to explain it's your application now what is going to happen is that a service provider and an identity provider are going to speak uh you know i mean they are going to communicate to each other so there has to be a request and a response you know being generated and that's what it is called a sample request it's an authentication request generated by the service provider to requesting authentication so now what happens is like a user is trying to get into an application a user is you know trying to access any application and uh there would be you know if the user would first be going to the application and maybe let's say the user wanted to access zomatos the user went to the application somato and you know directly hitting the link one browser on his phone maybe opening the application and then from zamato the so matter will understand okay this user wants to leverage my services now if there is you know an identity provider and a service provider service provider is your matter in this case these two entities will you know have to speak to each other now zomata will understand okay this is the user i need to check whether this is a legitimate user or not i cannot allow this user to leverage my services without before authenticating the user so eventually what is going to happen is that so matter is going to send an authentication request to google okay so that's what right that's the sample request when an authentication request is being generated by the service provider that is by your application to the identity provider and what it is generally doing is that it's asking or it's requesting for an authentication it's saying to the identity provider this is the user please authenticate this user if you feel this legend this is a legitimate user please come and tell me i will you know allow this user to enter in my environment and leverage my services so that's what a saml request is then you know if someone is requesting there has to be a response to it right so uh once uh like now the request is gone to the identity provider now a response has been generated by the identity provider it contains the actual assertion of the authenticated user in addition a sample response may contain additional information such as profile information group roles information depending on what the service provider can support so basically once the sample request goes to the identity provider that is the one who is going to authenticate the particular user like you know the request to authenticate a user basically now idp is going to do its work its role its job so you know it's basically going to authenticate a user and it will generate a response okay once it like it will say okay this is the username this is the password it will try to find its own data directory and if it is able to do so okay perfect now the user is being authenticated now it will create an assertion of other authenticated user assertion is basically your xml document you know having some information that okay you know when was the user authenticated when was the user uh like you know when the request came or you know when was the last login or you know when for how much time the user is being authenticated i mean a session is created for the user what all attributes are going to be sent from the identity provider to the service all of this is you know an assertion so it's kind of an xml document which is being sent from your identity provider to your service provider so in addition a sample response may contain an additional information such as profile information groups roles as i've just mentioned so you know whatever like service provider might be requiring certain details right it cannot just allow you to get i mean i'm just giving you an example of zomato and google but that doesn't mean like you know there are business applications which requires actually the roles you know i might be entering or you know getting into an application with certain rules like you know i do not have like full privileges for that application so i need to the application needs to understand what type of user is you know trying to whether it's a super admin user whether it's a normal user whether it's a business user whether it's a super user so you know there are different different roles for an application an application needs to understand okay this user is authenticated but what what level of permissions like what level of access or what page should i be showing to that end user so sometimes you know the application of the service provider asks the end user or the ind provider then please let me know what type of you know uh group this user is part of or you know some file information so that service provider can then i mean check at their end that okay you know this user is coming with this group so maybe he's part of this group then that means like he's a super user or he's coming as a part of normal users group okay i don't have to give him super super user building i'll just show him normal user space so you know there could be different different roles assigned so that's why service provider might require certain you know roles or groups or you know other information about the user in order to you know in order to take a decision what should be the landing page for the user so now a request and a response is needed so basically a request is from the service provider to the electric provider response is from the identity provider to the service provider now there are two you know i mean say concepts of uh sample one is your service provider initiated that is sp initiated and the other is your idp initiated now there isn't a much difference but generally this is you know one of the questions like you know being asked in a lot of interviews that you know if if you claim that you know you know sam then basically you know they ask that you know what are the different types of flows of salmon so these are the two different uh flows of sample one is the service provider sp initiative and the other is your identity provider that is idb initiative flow we will see that you know how these flow works both of these flows there isn't a much difference between these two clues but yeah so if i have to start with the service provider initiated blow then basically it signs in describes the sample sign in flow when initiated by the service provider this is typically triggered when the end user tries to access a resource or sign in directly on the service provider site such as when the browser tries to access a protected resource on the service provider site so if i have to you know explain in easy language so basically you're trying to get into the applications now like both ways like be the service provider or beat an identity provider flow both ways your end result is or your target is to get into the application right to get access to the application and you know there has to be some authentication door and something something will happen and your end result or target is that you want to get into the application right so now there are two ways to do it one is that you directly hit the application you don't go to identity provider you directly hit the application you directly go to the application url and you know you want to get into the system into the application so this is called as a service writing initiated flow because it is the sp from where the saml flow is going to be initiated because you are hitting your application first that's why and your application is a service provider that's why sp initiated because you are going to the application and then you are you know the complete sample flow will start you know that complete okay that the example request will be going from sp to idp response will be generated it will be checked whether the user is legitimate or not and then you know finally giving the access to the end user so this all of this will happen once you'll hit the application that is your service provider so that's why it's a sp initiative and identity provider initiative it's science and describes the sample sign in flow initiated by the identity provider instead of the saml flow being triggered by a redirection from the service provider in this bill the identity provider initiates a sample response that is redirected to the service provider to a certain users and entity so very basic why you know simple different between simple difference between these two flows is now there won't be any redirection so you know if i talk about sp initiated flow what is going to happen the end user is going to go to the application now application will redirect to idp generating a sample request right now in this scenario if you're directly going to the identity provider so in order to get into the identity provider you have to authenticate right you anyways have to authenticate because provider doesn't allow any identity to get into the system without having the access to it i mean without authenticating so you will be going to identity provider in high tech initiative you'll directly hit identity provider you will authenticate yourself and then you will get into the identity provider there you will see you know a chunk of applications whichever whatever they are integrated with the uh our i mean whatever is your access management tool and from there you will hit i mean you will hit one of the applications what you want to get into and then you will be you know redirected to the application if you are a legitimate user so it's like you know there is no redirection from sp to idp in the idb initiative you directly get into itp you authenticate yourself and there is a sample response which is being generated by idp at the time when you actually you know authenticate yourself under in idp and once you do that you know that response actually goes to the application and that's how you you know you access the application or libraries the services of the application okay so next we'll see some more terminologies uh with regards to some assertion so if i just mentioned you know assertion in the previous slide like uh what is an assertion in simple terminology it's a data provided by the identity provider that supplies one or more of the following statements to the service provider so basically you know a document which is suggesting okay you know this this information or you know when was the last login when the user tried to log in and you know stuff like that so it will just send certain information about the user to the service provider and that's a sample response so saml response is basically an assertion which is being sent by the identity provider to your service provider now under assertion we have you know one couple i mean three statements which generally is being saved by the identity provider to the service provider okay so basically what happens is like we have got authentication statement this is one of our assertion uh statement or you know one of the uh one of the things which is being sent under a sergeant i mean i am just talking about now three statements or three things which an identity provider sends to a service provider and this is uh this comes under assertion because that's like a sample response which is being generated so basically authentication statements tells us that you know asserts that the user specified in the assertion actually did the authentication successfully and at what time they did so so see identity provider is going to authenticate there would be two results whether the user is authenticated or a user is not authenticated right so if a user is authenticated then an assertion is being generated right and an authentication statement would suggest that the user who was trying to get into the application it's a legitimate user authentication is successful for that user and at what time the user was authenticated like you know maybe it's authenticated at 10 15 a.m in the morning so we need to lock that time so identity provider is going to do it because i think the provider is the one actually you know uh authenticating the user so that would be the best possible uh uh situation to you know tell us at what time the uh authentication is successful and then you know it will send the attribute statements so i have just mentioned the previous slide that you know service provider might require some attributes to be sent from the identity provider and now identity provider is having complete information about that user with all the attributes so whatever service provider requires you know identity provider has that information about the user so it can easily send that information to the service provider so that's like your attribute statement it will supply the attribute values pertaining to that user the name id attribute is required and specifies the username but other attributes can be manually configured as well so there has to be at least one or two attributes right like there has to be a mapping between an identity provider and a service provider so that's basically the name id format or you know which is basically the username of the because we say that you know for an organization a username of an individual is always unique even if we have burger couple of before those or ten reporters in an organization but every week is going to have a unique user name so that's really you know there would be a unique attribute which will be sent from an identity provider to the service provider but if in case we require you know more attributes to be sent from idp to service provider we can do it we can you know manually configure it uh then you know finally we have the authorization decision statements that declare a request to allow the assertion subject to access the specified resource has been granted or denied so you know finally it says okay i mean assertion is being generated whether the user is authenticated successfully or not now at authorization decision is like it will finally say yes or no i mean it will finally write yes or no okay if the user is authenticated yes allow that user grant access to the application if the user is not with indicated it will say no don't answer the application so it accesses the name so basically these three statements are being you know the assertion is carrying these three statements with it and this is you know this ammo response which will be going back to their service provider another important terminology is that this is you know one of the terminologies which is being asked in interviews a lot of time what do you understand by acs or an assertion consumer service url so we have just you know understood us what is assertion okay an assertion is a document which will have certain information about the user uh and you know certain like what kind of authentication whether the access is granted in some attributes and this is being generated by your identity provider and it will finally go to the service provider this is your assertion now a session consumer service as the name suggests now this assertion has to be consumed somewhere on the service provider side right like because idp has done its job idp has generated a response and now idp is saying that this is the assertion i have created now it's up to the service provider what they want to do whether with this assertion so there has to be an endpoint url on the service provider side that is responsible for receiving and passing the saml assertion it's going to be in the xml format that's why it requires a passing and i just mentioned right like okay attribute decision would be or authorization statement decision would be that it will write here some but that's not going to happen like just to explain you guys i am you know talking in simple terminologies but it's going to be an example format so it requires some parsing it requires some decryption of data whatever is coming from the effective provider that okay you know what does this mean service provider has to understand that so basically that is what your ecs is all about the service provider there has to be an endpoint url and it it cannot be your application url the login url which you use for your application definitely it cannot be that you are uh generally you know this is the url which is being generated by the service provider itself so whosoever you know on the application site they want to have a sample integrated so you know they generally have this information from octa's point of view you know we can we cannot generate this information at any time this is you know something to be provided by the application team so we cannot do anything on this thing so it's basically uh like the endpoint url that is responsible for receiving and passing the sample assertion keeping in mind that some service writers use a different term for acs in octa sample it is being used as single sign on url so some of the access management tool or some of the products of access management you know they they term it as the single sign on url some of them say it as acs url but they are you know one at the same thing so acs url or single sign on url um you know whenever someone asks you this question they mean the same but the important point to understand is that they this is you know the service provider is actually having the url which will be consuming that assertion you know which will be actually going in parsing and you know understanding what the identity provider has and because one if it is like the identity provider is sending some response but if the service provider is not understanding that response then what's the point of getting a response right identity provider is sending something that service provider has to understand it and that understanding of what idp has sent is known as pcs and at what point or you know at somewhere it will it will just you know pass the the samuel assertion and it will understand okay this is what the idp was saying or it was trying to communicate to us and according to the decision what itb has taken whether users should be granted or not what attributes and all the user is finally giving us given access to the application so that's what your assertion consumer service url is next we have attribute it's a set of data for a particular user any you know profile data so that's what is your attribute it could be your first name last name username email employee id or you know location work email anything so anything any data pertaining to a user and you know i mean pertaining to the profile of a user that is your attribute uh then you know what is an audience restriction so basically a value within the sams assertion that specifies who the solution is so now basically what is going to happen is that you know there are going to be multiple applications within idb like you know they are like we have got multiple chunk of applications being integrated by a single id we are not you know think of a scenario that you have got 100 applications and each application is having a connection with only single idp there are not 100 idps for 100 application there is one identity provider that is your octa which is going to be integrated with multiple application now every time octa is going to authenticate how will it know that you know that for which set of uh application or you know for which application it is it has to create an assertion for there are multiple or hundreds of applications being integrated in octa so any request sample request coming to a needs to understand right like which application is asking me a sample response right so that's why there is an audience url or an audience restriction which helps us to understand which application every uh application has its audience url or you know an audience restriction url which helps octa or the identity provider to understand okay this is the one for which i have to you know generate a response so that's exactly what is your audience restriction uh and also like you know sometimes the audience restriction and the acs url that is a single sign on url they are saying most of the cases you'll find they are not same but if in case they are it is not being provided by the identity provider then i mean by the service provider then you know we treat that okay the acs url itself is the audience restriction but ninety percent of the train uh it has to be provided by the service provider that is your application uh then what is the default real estate uh it's basically the url that users will be directed to after the successful authentication through xaml so that's your real estate then endpoint are the urls that are used when the service provider and identity providers formula so that's your end point then ndd id is your a global unique name for an identity provider or a service provider so as i've just mentioned right like it's something like an audience just section but not exactly but because like entity id is something like you know identity so there is a unique name you know for every identity provider and a service provider and that unique uh like you know i mean like for example let's say that you've got five applications of salesforce so every salesforce application will have something unique right which will differentiate it from the other four applications so that's what like you know even if an octa so there cannot be just one option right like you can have multiple octa 10 instead so that's why uh like you know there would be a n and an ndd id that would be unique for both servers whether and your identity provider and you know that unique identity is being generated by for each application when we talk about doctor and it is referred to as the idp issuer in the author's application set of instruction so you know but whenever you generate or you know you uh create a connection for an application in octa it will actually you know create a unique octa entity id and that's you know basically we call it as identity provider issuer in octaz application setup instructions then identity provider is something we have already understood it's the authority that verifies the and asserts a user's identity and access to a requested resource uh then metadata this is important now what is a metadata middle data is basically you know data over about data but like i just mentioned you know the concept of trust between i mean between your service provider and your identity provider there has to be some trust now this metadata actually allows you to you know maintain or you know create that trust between these two entities okay it's a set of information supplied by identity provider to the service provider or vice versa in the xml format so you know like whatever this exchange of information is going to happen right between an idb and sp that's like somewhere it has to be you know uh like i mean consolidated and that that that set of information is is known as metadata so what happens is basically when we are creating a connection right with your service provider or your identity provider the service provider supplied metadata will typically provide the ecs url your audience restriction name id format your certificate and if the assertion needs to be encrypted and at this time sp supplied metadata cannot be imported into our idb supplied metadata will provide a single sign-on url entity id x.509 certificate which is required by the service provider to decrypt the assertion so you know any like let's suppose that there is an assertion and any assertion cannot be decrypted by any identity any service provider right there has to be a trust like which will actually you know allow that assertion to be decrypted uh i mean to be passed like now suppose like i have my own identity provider and uh i you know generate my assertion and i say i go back to the application side like just decrypt it like like now my application doesn't know if what is the identity provider then how will it decrypt it right like it's not just something that you know i can just go to google and i can just you know type in my or get my assertion and it will decrypt so there has to be some trust there has to be some set of information exchange between these two parties which will allow you to you know do the process and this metadata you know is actually your integration steps or your integration steps so basically whenever you want to integrate an application first thing you ask is like to the application help me with the access your reporting restriction name id format the certificate and once you get that you will you know you configure this connection on optim and you know you provide them your metadata to octagon which contains you know information like single sign on url entity id uh certificate so you know this is the set of information which is being required by the service provider in order to decrypt the assertion which octa is going to send whenever the authentication request will be generated so that's what your metadata is all about then name id is again an attribute within assertion that is used to specify the user name so we just mentioned this thing above then the service provider is the hosted resource or the service that the user intends to access such as a box workday salesforce custom application etc so basically you know your application now for which you want to use the services and your single sign on url is something uh similar to your acs url which you have just mentioned about so it's the end point that is dedicated to handling sample transactions in opta samuel template setup screen these single sign on url refers to the service providers url okay so these are you know some of the terminologies what we understood we have a service provider we have identity providers sample request sample response then what are the two types of flows that is service writing achievement flow or an idp initiated flow then you know going deep into the terminologies like what is an assertion what types of statements are does an assertion contain then you know what is your easiest url then what's an attribute what is your entity id or an audience restriction then you know a real estate and then finally your metadata concept so we have understood all the terminologies that we should uh you know know before jumping onto the sample flow okay so now you know finally this diagram actually helps us to understand you know what is an idb initiative flow what is an sd initiative flow and now you know let's go one by one step by step so as an end user you are sitting on step one now you want to access the service provider on any application so as an end user you go to the browser and you hit the url so you end user access service provider from the browser you go to the link of the application now if you are going to the link of the application that means you are going to step two and from there your sp initiated flow is going to begin from service provider it will redirect the sample request back to the browser and from the browser browser release the sample request to the identity provider because identity provider is eventually the one who is you know going to authenticate the user so from step two your exp initiative flow has started now i have mentioned that in sp initiated flow there is always a redirection from the service provider to the identity provider so you know you will go from step two to three that is to your browser and browser will redirect you back to the identity provider and from step four now this is the place where your idp initiated flow will begin now from step 4 idp will authenticate the user it will identify and authenticate the user once the identity provider is satisfied it will generate a sample assertion now this is the place where at step 5 where the assertion is being generated and it's sent back to the browser now browser has got nothing to do with the assertion because browser cannot you know consume that assertion so it will go to the service provider browser will you know browser release the sample assertion back to the service provider now at service provider it will check it will pass it will decrypt the search and having that inform how will it decrypt it will decrypt because service provider has a you know some of the information what octa has already provided or the identity provider is already provided that's why it's able to gen i mean decrypt the uh information of the assertion and it's happening because there was a meta data exchange between the service provider and the identity provider now if the user is authenticated service writer sends the security context to the browser so you know it says okay allow this user now the from the browser it request resource from the service provider and then finally the requested resource is being granted to the user so this is how you know the flow is all about if you see that idp initiative flow you don't have one two and three steps because directly from identity provider you authenticate an assertion is generated and it you know from four to nine it happens but if we talk about sp initially one two three you know these three steps are also there now you know there is no comparison between these two pros you know it is basically on the requirement like if someone wants to have an idp initiate flow then they go ahead with idp if there is a requirement for sp initiate flow that depends on sp both are you know exactly the same thing i mean only three steps but like that's like a millisecond so you know you won't even realize that okay this happened okay so so it's something you know based on uh the requirement of the application team if they require their use end users to authenticate first hitting the url of the application and then getting authenticated it's nice if they want no we want our end users to you know directly login to octane then authenticate that's also completely fine so you know we uh these are the two flows which actually helps us you know achieve this single sign on using sum so yeah that's what the saml is all about uh next you know i'll quickly show a demo of how do we achieve sample uh so you know i'm i'm going to create a dummy connection in octa so you'll see that you know there's a dummy connection in octa i'll create an application now i don't have any application access so i'm going to you know use one of the application which can be i mean this is the kind of you know uh application i mean it's also a dummy application and it can be used anywhere so i'm just going to use that and now if i go to the instruction so what are the first things i need to exchange the metadata because i what basically as a part of integration i need to maintain a trust between my octa and the application so let's suppose this is my application and this is my octa so i'm going to create a trust so i'll go to the create an application integration i'll go to saml new then maybe my first samala then i've got an option to you know upload the logo then under application visibility i've got couple of uh options so you know if i just tick mark this option then i cannot do an idp initially flow it will not be available on my dashboard so i cannot do that but if i uncheck then i can do both some exp initially as well as idp initiative now i go to next i need the single sign on url this is your ecs url which we have just you know understood so i need to get the acs so i will then download the sp initiated flow i mean sorry service providers metadata so let's download that so this is my service provider metadata and i need to give this single sign on url so i need to find the single sign on url over here so this is my single sign on url you know you can see that the endpoint contains acs also so this is going to be the place where you know i am going to my assertion would be consumed then i need to one find the entity id this is the ndd id or the audience uh restriction what we have just studied that you know so this will you know extract from here and you know we'll copy paste here uh next is that if default real estate if you don't have we can set it blank name id format is here by default it's a username so you know it's going to send you the username and these are you know your attributes so maybe if i want to send an answer let's say so i i can just send my attribute okay so this is i'm using an opt expression language um so you know we'll talk about this language but uh right now you can think of that identity provider is you know sending some attribute value to the service provider i can send group attributes as well but currently i don't have any so i'll i'll not send anything next is we'll go to next and we'll just you know finish the configuration settings now once we have finished the configuration settings now a connection in opti has been created now i will you know i need to assign this application to myself because i'll be the one who will be testing this application so i'll go ahead and you know assign this application and now once would i would have assigned right so i would see that you know on my end user dashboard i would see an application with this name you could see right my first family so you know uh this is our idb nation i i would have you know i have already logged into the octa so i have a session with doctor but now if i would have you know logged into octane then uh hit this so this is your idbi nation i'll demonstrate how do we do that but right now uh let's complete the configuration so i have you know from application side i have extracted the metadata and i have added that metadata in octa now from idp site i need to get the metadata and add that metadata over here so i'll just copy paste this metadata and i'll go to the application [Music] and i'll you know paste this metadata over here and i'll submit the exhibit so this is my you know service provider flow like this is the url what this application has provided me saying that you know just trying to get into the application so i will you know open a new incognito window and i will try to get into the application i am hitting this link just see that this is the application url this is not the option so i'm just hitting this link now so see i'm being redirected to opt-out right so i'll just log try to get into the application sign in so now you know there would have been an uh assertion which is being or a sample response which is being generated uh once this authentication will be completed by octa and once you know once this is completed then uh i would be you know redirected directly to the application see and this is i'm you know trying to get it and you know there i am so i have you know successfully logged into the application and if in case i would be you know using this particular link also so i have a session created with my browser you could see and then you know again i'm getting into the application so whenever i have a session created with the browser i mean like with octa so i don't have to authenticate again and you know that's why i try to go over here and check whether i have a session i mean in a new incognito window but uh you know i'm actually using my gmail account you know to get into the system that's where this you know this is causing an issue but if in case you have normal uh you know your username and account then it won't be an issue right so this will this will work smoothly so yeah that's it like you know uh this is how i'm getting into the application you could see that you know whatever are the attributes which has been sent by the you know this is these are the assertion details like you know you'll see that what is the entity idea search and id hashing algorithm conditions and you know something so all all of that you know you could see the complete assertion value over here so this is how you know our and also i was sending one of the attributes right as email so you could see that you know that email attribute value got sent from the identity provider to the service provider so yeah so yeah that was a quick demo of you know how do we do a sample integration using octa and next you know we'll cover the oitc integration the oidc as well as award flow uh we'll you know look into what uh what and why dc is all about and then we'll move forward to the admin ui so basically right now we have covered you know what a single sign-on is and you know under single sign-on protocols we understood there are different uh single sign-on protocols which include saml oidc ws secure web authentication and today out of you know uh those we are going to see what because we have already seen channel we have already gone through the sample content now we are going to see the work or the oid sso protocol so these two you know basically saml and works they are the kind of standard protocols and we know they have been mostly used and for uh these single sign-on practices whereas secure web authentication or ws fade or ws does you know there are some of the protocols which we don't use much when compared to single sign i mean when compared to saml and oauth or oidc protocols so basically if we you know if i have to define what what 2.0 is all about why we are going to you know study first before oidc is because oidc is you know kind of an extension of what only so it's necessary that we understand oauth first and then you know we'll move on to the oidc protocol so or2 is an authorization framework uh you know this is a very important thing to remember because this has been often asked in the interviews that what kind of a protocol it is whether it's an authentication or an authorization your saml is an authentication and your oauth 2.0 is an authorization framework so it basically enables the application to obtain limited access to the user from so you know once you are authenticated there has to be a limited access for each user in a particular application so that's what it enables the applications to obtain limited access to the user accounts on a http service such as facebook github or you know digital solutions or many any other application it works by delegating the user authentication to the service that supports the user account and authorizing the third party application to user the access account to access the user account what two provides the authorization flows for web and desktop applications as well as mobile devices so basically what it is doing is like you know it is uh like uh there there will be two-way contact one would be you know the user trying to access the application and then another would be application you uh trying to access the user information now both of them would be delegated like you know a user can will not will not have full access to the application that's where you know the roles or the authorization part would come into picture and then the application itself wouldn't have you know the complete information about the user so you know again kind of limited or certain information would be granted so that's what you know of 2.2 is all about now if i if you know if you want to understand the roles of oauth then you know it basically defines us four roles one of which is resource owner then we have a client credentials then we have resource server and then the most used used one is the authorization server so basically you know before i move on to these flows and you know we basically understand what are the different types of flows which we have under oi dc i would rather like you know go ahead and like you know have a go through on the terminologies of what we have in ydc so very first terminology or the very first doctrine which we need to understand is the resource owner so the resource owner is the user who authorizes an application to access their account so the applications access to the user account is limited to the scope of an authorization granted so you know basically the resource owner is going to be the end user who is you know who wants the application to be authorized or you know who authorizes an application to access their account and then who you know who is basically trying to get into an application based on their roles in the application so you know they are basically trying to authorize an application based on their account permissions and once the applications access the user account is limited to the scope of the authorization granted so you know there are scopes which we'll understand you know later but like right now you can think scope is something which will help the application to understand what level of permission the user has whether it's a read write or you know edit modify what level of permission it has so you know basically the applications access to the user account has been limited through a scope of the authorization granted that is that would be either read or write or you know both whatever access the scope says so that's basically the resource owner now we have an authorization server or an api this is an important thing to understand so the resource server hosts the protected user accounts and the authorization server verifies the identity of the user then issues the access token to the application so basically you know what happens is that we we have a resource owner then we also have a resource server now that resource server is going to host the protected user accounts and the authorization server is going to verify the identity of the user and it will issue the access token only once the identity has been verified so you know basically your authorization server is going to authenticate or you know verify the user uh you know it's not directly authenticating the user but it's kind of you know it it has to understand or it has to you know check whether it's a legitimate user trying to get into the application so kind of a pseudo authentication which will happen once it's satisfied that you know yes it's a it's a legitimate user then it will you know grant you an access token and then you know you can go ahead and you know access different uh resources which we have under the application so from an application developer's point of view a services api fulfills both the resource and the authorization server rules we refer to both of these roles combined as the service or the api role so you know basically this fulfills both the resource and the authorization server for server roles and you know we can combine them and we can term them as the service or an api rule then we have a client which is an application so client is the application that wants to access the user account before it may do so it may be authorized by the user and the authorization must be validated by the api so basically the client or you know the client or the browser it's an application which wants to access the user's account you know so whatever user is trying whichever user is trying to get into the application the client is the one which wants to access the user's account and before it do it it it will do it you know it has to be authorized by the user you know authorization see the user has to grant the permission uh i mean an application cannot directly uh get or you know access the user's account without being asked so you know you can take a take an example whenever you you know install a new application so you are being asked whether you know you want to allow notification you say yes or no you are being asked if you want to access you know you want the contact list to be accessed by the phone you say yes or no i mean to be by the application you say yes or no so all of these pop-ups are something you know which like the application wants to use users information but application will ask the user whether it can do it or not and now it's up to the end user whether they allow it or not if they are granting them access then they are saying yes you can if they are not granting them access then they are saying no you cannot so that's how it works next you know some of the other terminologies which we have in uh one is the redirect url so basically the url the authorization server will redirect the resource owner uh resource owner is the one you know who is going to be authorized envy basically the end user it will redirect the resource owner back to after granting permissions to the client so you know so basically the redirect uri is something we have understood what is the authorization server it's basically going to verify the identity of the user and then provide an access token then resource owner is something you know who is trying to it's basically the end user's account and then the client is the application that wants to access the end user's account so basically the direct url is something the url that the authorization server will redirect to the resource owner back to after granting permissions to the client so resource owner is going to grant permissions to the client and then the url the authorization server will redirect back to the resource owner so this is sometimes referred to as the callback url so what will happen is that the resource owner is going to grant permissions to the client and once it will it has granted permissions the it will redirect back to the authorization server and that url which redirects back to the authorization server will redirect it to the resource owner which in turn will you know redirect to uh to grant the permissions to the client so this is basically a callback url then there is a response right the type of information on the client expects to receive the most common response type is code where the client expects an authorization code so you know response type is something like you know it could be your identity token it could be your access token i mean something which you are expecting back in response so you know basically the most popular thing to expect back is uh a code you know basically we mostly use authorization code flows in when we talk about ydc so you know that's where we get a code in return and that's your response type so the type of information that the client expects to receive and the most common response type is the code where the client expects an authorization then scopes these are granular permissions the client wants such as access to data or to perform actions then consent is something the authorization server takes the scopes the client is requesting and verifies with the resource owner where whether or not they give they want to give permission to the client or not so even basically whenever you are granting permission to the client whether they can access something or not based on the score scopes are you know your granular permissions uh which is trying to get the user's information so if you're granting them your concept to you know have your data being read or you know right written by the client that is your concern and that that is something we can term it as consent then you have a client secret so this is a secret password that only the client and the authorization server know so you know this allows them to securely share information privately behind the scene so you know client id and client secret is something which we require in order to you know verify our identity in front of the by the authorization server so it's kind of a secret password that only the client and the authorization server knows and this allows them to securely share the information privately behind the scenes then an authorization code is a short law short-lived temporary code the client gives the authorization server in exchange for an access token so whenever you get an access token you have to provide an authorization code and then only you are being granted an access token then if we talk about access token the key the client will use to communicate with the resource server this is like a badge or a key card that gives client permissions to request data or perform actions with the resource server on your behalf so once you know your identity has been verified and you know you have granted permissions to the client now you know an access token is being granted now once you get an access to open it you know as the name suggests access token so you know you are basically going to in that particular token you are basically going to have whatever access you have you know uh or what of what all resources you have to access on an application so that uh token will help you you know get through to you know whatever uh scopes or whatever access you have within the application so basically you know we can think of it like you go to a fair there are you know you you you know you purchase a ticket and in that ticket you know you might have three or four swings which are free of cost for you right you you you cannot definitely have all swings for free of course but you might have you know maybe a purchase of 500 rupees ticket and you know you might have three or four swings which are free of cost for you so you can you know go one by one and have them have the access to those things similar is the case with the access token once the access token is granted to you so whatever are the permissions you have based on your rules or you know based on your profile you can you know go ahead and you know request for the access of those particular resources so that's what where access token helps you today so basically if you want to understand the abstract flow of you know the oauth 2.0 so basically you have an application that is your client which actually makes an authorization request to the end user now author as a user you are going to grant them your consent that is the authorization grant is being you know granted and then once it's been granted the authorization server provides an access token and once the access token is you know come you have been granted an access token so this is basically you know your ticket counter and this is basically your swings you know once the access token is being provided to you by the resource server then you can go ahead and you know access anything in the resource api or you know the service api or the resource server so you know whatever other protected resources you have and whatever access you have got based on your access token you can go ahead and you know actually access those resources so now if i talk about application registration before using what we with your application you must register your application with the service this is done through a registration form in the developer or an api portion of the services website where you provide the following information so you know basically i am also going to show you like you know how do we um okay yeah so i will just show you that uh how do we register in our 2.0 application in knockout so you know in the meanwhile the environment sets up okay so basically this is you know what we are going to do we will go to the applications and you know we will just go ahead and we will go to the oitc one and over here we we need to select you know what type of an application we possess or you know we are trying to integrate it so we in most of the cases we are going to use a web application my first was app may be and over here you have the grant type so you know this is something that types are the you know the rules or you know the flows in which we can you know have an oitc or an earth being set up so you have client credentials authorization code or refresh open or implicit type and over here you have to you know give the redirect uri so we just mentioned you know back here what is a redirect uri then you have to give you know what is the redirect i mean sorry login redirect qris and log out ev direct this is kind of optional but this is something you need to give because this is kind of you know once you have been authenticated so it sends back the response to this particular url so you know you need to read this url in order to you know get access to the access token and then finally to the resource server so you just you know maybe i'll just give i'll just give the default urls whatever we have and you know this is something if the request is coming from some other domain like basically this is my domain right now and if the request is coming maybe from sharepoint or you know somewhere else like outside of this particular domain i have to add it over here in the trusted division domain so that's that's pretty much it and you know once maybe okay uh we'll just skip the assignments of people for the timing and once you know uh once my application now my application is registered with doctor you know now this is something i need to provide this to the application team so you know whatever is the application name let's suppose we have we do have an application with this name then i do have to provide them the client id and the client secret and even this is where we i am like if i want to understand this thing so you know this is an application this is an end user who is trying to get into the application now this particular application will be corresponding or you will be communicating to the authorization server or the resource server and these two things is something which will be provided by octa in our scenario so you know basically an application request will go to the user from the user it will grant the access from access it will you know ask the authorization server to get give them the you know the the access token once the access token is being granted it will go to the resource server and finally access the resources so this is how an abstract flow looks like and for us to do so we require the application to be registered with this you know identity provider which in our case is going to be after we have registered that once we registered it we need to provide the client id and the client secret to the application team so you know basically this is something they are going to authenticate themselves over here once they get this authenticated or you know verified by the authorization server it will grant them the access token so they know this is something we have to do for the registration bar so you know that's what you know we have written here that before using or2 with an application you must register your application with the service this is done through a registration form in the developer or api portion of the services website where you will provide the following information which is the application name application website to redirect url or the callback url and redirect your raise the service which will redirect the user after they authorize your application and therefore the part of your application that will handle the authorization code or the access token so you know basically once you have given your consent or not given your consent based on your response that it's going to be the url where you know the authorization code in the access token is going to be granted or you know you are it's going to you are going to get that token or report that that particular url and once you get that you need to you know extract that code or an access token and then finally go to the uh resource server with that code saying that you know it's kind of a ticket you know so wherever you can receive your ticket it's kind of that particular url so once you receive your access token you are going to the resource server to asking them that you know i require these these resources to be accessed and they'll check whether you have an access token whatever access token says that we have access to we'll be allowed to uh you know get access to all of them so that's what it is and that's what your registration of an application is so once your application is registered the service will issue your client credentials in the form of a client identifier and a client secret so the moment you remember you would have seen that you know we clicked on save our client id and client secret was generated you know so moment the application got registered the client id and the client secret got generated and client id is a publicly exposed thing that is used by the service api to identify the application so you know basically this is kind of in ntt id we studied you know what is an entity id and samuel it's kind of a unique attribute or a unique value which you know ah differentiate or distinguishes an application from other application so that's what the client id is all about so you know it's basically the application what is a client client is your application and it's the identifier of the application so basically that is what the client id is all about and once you you get your identifier generated you need to you know it's being used and it's being exposed publicly and it's being used by the service api to identify the application and it is also used to build the authorization urls that are presented to the user the client secret is used to authenticate the identity of the application for service api when the application requests to access a user's account must be kept private between the application and the api so basically you know over here the application is going to be authorization server with the client id and client secret and over here if this is a legitimate and if it is being verified between these two entities then only you are being granted an access token so that's why it has their client secret has to be you know kept as private between these two entities it cannot be you know made public so because if it is made public then you know anyone can go ahead and make a connection with the authorization server and they would be requesting uh for foreign authorization code or an access token and based on your client id and time secret that would be granted so you know uh we need to be extra cautious that our client secret should not be you know shared with anyone okay so now next you know we are going to see the different types of uh grant types which we have in board 2.0 so the very first and the most used one uh that we have is the authorization code flow so you have the resource owner that is the end user then you have an application then finally an authorization server and your api so you know basically i'm talking if i have to refer to this i'm talking about you know application user authorization server and the resource api right so i'm basically covering all of that so now you know uh what happens is that you know if the user goes to the application you know so it will click on the login link it will go to the application now from the application the user requests the authorization code to the auth server so you know over here the client actually does not directly go with the client id and the client secret instead it will request for an auth code from the authorization server once the auth code is being requested the authorization server redirects to the login slash the authorization prompt you know it will redirect you back to the user and over here now the user is being asked okay you know that this particular application is requesting access to this thing would you grant access or not you will say yes or no so you know you are eventually going to provide your consent to that request being generated if you authenticate and consent is being provided then the auth code is being provided by the authorization server to the application now the authorization code is there with the application client id and client secret was something which the application already had because your application once the application was registered we had already provided that client id and client secret to your application so now authorization code is something which is being granted when the user gave its consent and client id and client secret is being provided already to the application at the time of application registration so now the application is holding three data three data points that is one is authorization code one is client id and the other is client secret so now it will go back to the authorization server it will validate the authent authorization code as well as client id and the client secret if all of these three are you know being validated by the authorization server it will provide you the identity token and the access token now identity token would be granted if you are talking about oidc that is your open id connect if you are not talking about oidc then just you know remove this identity open and only access token would be granted and that's what the difference between this oauth 2.0 and oitc is so you know basically what 2.0 you do not have a login screen in oidc you have a login screen and when you are trying to get into the application you know you are being provided with an identity token as well as with the access token so that's what the difference between these two uh you know flows are i mean these two protocols are we are going to eventually see you know in detail a little bit more on what oidc is but you know now wherever that authentication is you know direct authentication is coming into existence that's where your authenticate that's where your oidc is you know and if it's like a pseudo authentication so it's kind of you know then you're post 2.0 let's suppose that you know you did not have a login screen over here then also there would have been some validation right validation of client id and client seating so what is the validation it's kind of an authentication only right that you are going in with your client id and client secret authenticated by your authorization server now over here you are you are having a login screen so you know that's where like you know as an end user you are thinking you are doing a login so you know that's why oidc is an authentication protocol but in oauth 2.0 you are not doing a login you do not have a login screen so you know you are eventually going to do authentication in a sudo manner you know end user doesn't know that so you know your application is eventually going to do that authentication you as an end user does not have to authenticate you only have to grant permission but in oitc you as an end user have to authenticate so that's the difference so you know would you have been provided with the identity token and the access token once you know it validates the auth id token and the access token and once the request now you know with all of this data once everything is being provided by the authorization server that is your id to open an access token has been granted now the app requests the user data with the access token you know so it goes to the api server this is the server which is holding all of the information about your about the user so the application of the client will go to the resource server or an api server and it will request for the user information whatever in the access token it has it will you know just send back the response to the application and that's how your authorization code flow works so you know only thing is that you know in the authorization portal that you get an auth code first and once you get an output you validate your author client id client secret with your authorization server and only after you validate with your authorization server you are being able to get the identity token as well as the access token so this is you know basically the client the flow which is being mostly used in case of web applications you know and over here when i and when i selected this thing right when i went into this and you know i i had to select you know what type of an application i'm trying to integrate maybe i'll just so i'll just you know over here once i selected ydc i had to select you know whether it's a web application single page application or a native application so we have different different flows or different different you know grant types as per the use cases we have for the application so if it's a web application 95 of the times you will see that you know you'll use authorization code if it's like a single page application then you know you might be using implicit you know grant types which we are going to see now so basically based on the grant types we are going to see you know what type of uh you know based on the application sorry based on the application we are going to see what type of plant type we have to you know go ahead with next comes the you know the client credentials grant type now in this scenario there is no user you know so basically what happens is it's like machine to machine authentication so you have a machine which is trying to authenticate itself and you know or authorize itself and there is no end user there is no end user to give consent or stuff like that so you know just think of it same thing but you know this end user is gone now so that's your machine to machine authentication that is m2m uh you know you have an application not a client then you have an authorization server and then you have your api so basically the machine is going to go to the tenant or the authorization server with the client id and the client secret it will validate the authorization server is going to validate your client id and client secret once it validates the access token is granted it will request data to the api server with the access token which is granted and finally the api server is going to send back the response to the machine to machine or your application so you know it's very simple the only thing is that there is no concept of authorization code or there is no concept of user over there so you know there is no resource owner or the end user so you know it's your application or the client which is directly you know communicating so it's basically wherever there is no intervention of the user and sometimes you know you require apis to be authenticated via oauth so at that point of time we require machine to machine credentials or the client credentials grant type then we have the implicit flow over here you again have a user you have a client you have an authorization server but over here you don't have the api server or you know the resource server so basically as an end user if you're using oitc you'll have a login screen if you're not using odc you're not going to have a login screen the user will go to the application from the application it will request a token and once the token is being uh you know it will request for a token it will redirect you back to the end user or you know there is the resource owner where it will ask you to authenticate and give your consent once you give your consent it will provide you the token so over here the security wise it is less you know it's not com it's not very good because you know you you don't get an output and that is not being validated it's exactly same what happens over here the only difference is that over here you have an authorization code to validate as well over here when when the authorization server sends you back to the to the end user over there you authenticate and give your consent and you know you are directly being getting access to the application you don't have an auth code you don't have to validate again at that point of time it will just provide you directly the authorization i mean the the token so you know your authorization server will provide the application that open and you can just you know get into the application so that's like you know for your single page or native applications or your legacy applications where you know the web application versions are not supported at that point of time just to have the oauth or you know the single sign-on protocol into picture you can you know use this particular protocol so that's what your why what 2.0 is all about all you know the different grant types which we have in over 2.0 next you know we are just although we have you know seen what's the basic difference between an over 2.0 or an oidc but you know we'll just uh read a little bit of what oydc is all about so it's an interoperable authentication protocol i've mentioned bias with an authentication protocol because you are getting a login screen to you know uh to enter your password and credential and then you know finally give your consent to so that's why you know it's an authentication protocol rather than the authorization protocol and it's based on the oauth 2.0 harmony of specification so you know it's it the user straight forward the rest of the json message flows within a design goal of making simple things simple and complicated things possible it's uniquely easy for developers to integrate when compared to any other any preceding identity protocol so it lets developers authenticate their users across websites and app without having to own and manage password files for the app builders it provides a secure verifiable answer to the question what is the identity of a person currently using the browser or native app that is connected to me oidc allows for clients of all types including browser-based javascript and native mobile apps to launch sign-in close and receive verifiable assertions about the identity of the signed-in users so basically you know your identity authentication plus both 2.0 is equivalent to your ydc so you know you have an over 2.0 if you add a layer of identifying or and authenticating the user that becomes your oidc that's it like that's the main difference between an oidc and an over 2.0 so it it can also authorize but you know the primary purpose of oidc is to give you authentication what 2.0 also can do the authentication but that's like a pseudo authentication so primarily the work of order you know the objective of what 2.0 is to do authorization and primarily the objective of oidc is to do authentication although both can do both but you know that's what the primary purpose is so or 2.2 is designed only for authorization for granting access to data and features from one application to another oidc is a thin layer that sits on top of oauth 2.0 and that adds login and profile information about the person who is logged in establishing a login session is often referred to as authentication and information about the person logged in is that is the resource owner it's called an identity when an authorization server supports oidc it is sometimes called an identity provider since it provides information about the resource owner back to its clients so that's what the difference is like you know whenever you get the authorization server which you know sends back the information to the identity provider uh it's the resource owner credentials flow that we have to use oidc enable scenarios where one login can be used across multiple applications also known as single sign-on for example an application that could support single sign-in with social networking services such as facebook or twitter so that users can choose to leverage a login they already have and a comfortable user so you know and basically you would have seen a lot of times you know if if you want to log into any application you get an option sign in with google sign in with facebook so that's you know basically most of the places you will see that you know that's oidc being you know implemented straight away mostly wherever you will see you know sign it with google 95 of the times it's oibc flow which is being implemented at that point of time so you know it basically helps user uh even you know i you would have seen that you know i logged into this particular account so you know if i just have to sign out and show you again so i do you know i i go here and i sign in with google so you know this is basically an oidc connection what it is i'm not directly you know using my username and password to get into instead i'm using my google's account so you know that's where it my google would have authenticated and now you know i'm going to leverage the services of doctor so that's exactly what ydc is going to be so you know it's the perfect example of you know the oidc of how it works so yeah i don't have to you know create a separate password or credentials for my offer i i remember my offer and i remember my google credentials i trust google that you know it will my security has been is not being compromised and if i trust that you know so i can just use my single credential of google to get into the application instead of me you know creating different password again and again for different applications so that's where you know if you see somewhere social logins and if you trust those social logins so you can use that and eventually what are they doing they are using oidc you know that's that's the case what we are you know trying to understand so it's basically an oid of standard that profiles and extends what 2.0 to add an identity layer creating a single framework that promises to secure apis mobile native applications and browser applications in a single cohesive architecture it adds two notable identity constructs to what 2.0 uh token issuance model one is an identity token you don't have an identity token in that is something you get when you know when we talk about oi dc and the other thing you when we is that you know you get a standardized identity attribute api at a client which can be retrieved desired and identity attributes for a given user so what problem does ydc solve or 2.0 is not an identity protocol it's an authorization framework for securing arbitrary apis as opposed to abs fronting identity information so it's basically our over 2.0 is you know your authorization framework whereas your why this is kind of an authentication framework so that's where you know we require ydc to be uh to be brought on top of the or 2.0 so if i have to compare between oauth and open id connect so you know oh sorry i have to compare between open id versus open id connect so open id is your open standard for authentication being developed by the members of open id foundation whereas you know open eye and the problems which we face with why open id one and two was that the uri as they identified were too hard for the people to remember so not api and mobile friendly and no support for robust signing and encryption and whatever the enhancements that came into existence that you know actually were treated as the open id connect so that was the main difference although this is not very important for you to understand in the fundamentals part so that's fine and if you need to understand you know the basic difference between white open id oauth and finally sample so when or 2.0 the token or the assertion that is being generated is in the form of the json or the sample 2.0 or xml format you could say open id it's completely in json format and samuel it's an xml format uh or 2.0 yes it's an authorization protocol open id no saml it's an authentication but you know sometimes it can allow you to do uh authorization but it's like you know time it's very restricted or limited you cannot achieve authorization with saml to up to a great extent authentication i did mention that it does shoot authentication so or 2.0 does a pseudo authentication open id yes definitely a show it's an authentication protocol saml yes it's an oitc i mean saml is an authentication protocol then for the transport layer you know you use http for or 2.0 for open id you have you know get http post and you know so you basically have http get and post methods for open id for saml you have get binding and then your saml soap bindings and you know post binding so you've got multiple bindings under sample uh security list is uh risk if you talk about or 2.0 it's the phishing so or 2.2 does not support signature encryption or channel binding or client verification so instead it relies completely on tls for confidentiality so you would have seen that you know it's not a client idea client secret is something being provided by the by the end user or the identity provider who has registered the application it's not something client has something unique on your phone so it's not you know verifying the identity of the client so that's why you know a lot of phishing attacks happen when we talk about war 2.0 open id also there are phishing attacks identity providers have a log of open id logins so making a compromise about a bigger privacy base so you know basically whenever there are two parties you know because now there is an identity provider keeping a log of whatever the open id logins are so it's kind of a data or a security page uh then if you talk about saml so xml signature to impersonate any user so you know there could be a signature which can impersonate that you know you are not a legitimate user instead you can impersonate to become any user so that's again a security risk uh or 2.0 is basically the best suited for api authorization open id is best suited for single sign-on and samuel is also best suited for single sign-on so that's pretty much it and that's you know i know like it's a little bit uh difficult to understand open id but like we just try to cover the fundamental parts of what ydc and oauth 2.0 is all about so basically if i go to the octa screen right and if i go and see on the left nav bar we could see that there is an option called directory over here and this is what we call as you know the octaz universal directory so you know talking about a little bit more on cocta's universal directory uh the universal directory which delivers the rich user profiles and the fine grain control over how attributes are exchanged between applications this directory makes it easier for organizations to create and maintain a single source of growth for its users enabling new authentication and provisioning scenarios so basically you know this universal directory is actually you know deliver rich user profiles and they find fine grain control over how the attributes are being exchanged with different application so you know as we have seen before that we are integrating our applications with doctor now when we are integrating our applications with octa you know we we are sending certain attribute values from our octa to different different application and you know we could see that you know we were sending email attributes or we could send different different attribute values or different different you know user profile attributes values from octa to different application now how are these values being sent these values have to be stored somewhere right like okay what is the value of user or email for my account this value has to be stored somewhere right or i am i as an user have many attributes like you know i have a manager i have an email id i have a first name last name uh address you know local and you know country city state all these attributes belong to my particular unique id now these attribute values have to be stored somewhere right so this is all these attributes value are being stored in the universal directory of octa and that's why we say that you know they deliver rich user profiles and which allows us to exchange attributes with different applications it also makes it easier for the organization to create and maintain a single source of truth now why do we say that because you know octa is going to be your source or you know the identity provider which is eventually going to be integrated with a lot of different external directories these directories could include other directories like your active directory maybe your ldap directory may be you know your third-party directory or it could be your application uh you know uh application users which are being pushed into or pulled into opt-out so basically external directory users are pushed into octa and application users are being pulled into octa now there's a simple difference why why do we say that because you know uh if i talk about like you know octa sits in middle on the left hand side you can think you know all the integration to the active directories take place and on the right hand side uh you know all the integrations to the application takes place so integration to the application is like you know the out stream is like the out screen process that happens from octa to application whereas the directory process is like you know which happens from directly to off so you know it's kind of that's why we we say that whenever the users are being pulled into octa that means that you know it's coming from application and whenever the users are being pushed into octa that's where we say that the directory users are being imported or you know pushed into octa now uh what happens is like since the uh octa is going to be integrated with multiple directories or applications so basically the users of these directories or applications are going to be entered or you know their accounts are going to be found and going to be found inside of so now you know we are going to have multiple types of users we are going to have directory users we are going to have octa users the users which are created within octa itself and then we are going to have the application users the users which are created in application but on integration with doctor those users are being pulled into so you know we are going to have different set of users and basically what will happen is that you know eventually all of these users are going to sit within knockdown and that's why we can call you know octa as the single source of growth which will help us in all the authentication and you know provisioning scenarios with universal directory we have access to the profile editor in the admin console with the ability to store the rich profiles of user attributes and opera so what does this mean is like you know under directory you could see that you know we have a profile editor tab and now if i click and go on to this profile in the tab you could see that you know there are different applications which have been integrated with locked up so basically you can you know go to any of the application which have we have already integrated with octa why do we see all you know so many applications when we haven't integrated the reason being if you go to the application tabs we have got four active and 12 inactives so that's the reason like you know why do we see uh why we see so many applications over here had we like if we delete all the deactivated applications or inactive applications these you know these applications will go away all or only only the active or you know the applications which have an instance and octa will stay here so basically all the applications which have been integrated till date and they are found in october we can still see those applications over here also you know it helps us to identify or understand you know what type of an application it is whether it's an identity provider whether it's octa itself or whether you know it's an application which is like a third party application which we might have integrated either through saml or ibc secure web or any other api interface implications so now you could see that you know you have different different applications if you go to mappings you know you you have the ability to actually you know control what attributes should be passed from one place to another right so like you can see that from this particular application to octa what are the attributes that should be flowing in and then from octa to the to the application what should be the attributes that should be flowing in so you know we could save that mapping and that's where all of this is done under universal directory you can customize and extend the user and app profiles with custom attributes so basically the there are two types of profiles which we have one is the user profile and the other is the app profile so user profile is basically the profile of a user so basically any user which is created in octa that will you know if that is eventually not only created in october but has an account in october coming from you know either from external directory or from you know applications or directly created in octa will have a user profile so you know that profile of the user is going to contain many attributes so yeah so if you in case you want to use any particular attribute right right so like if you go to applications and if i go to one of the application over here so i was using you know one of the attributes to be sent from you know octa to the application and that attribute was email and i was using this particular you know expression language to you know send the value of this attribute so basically i'm using user dot so whenever you use something like user dot that's like you know user being acting as the class and you know email being acting as your subject or as the object so in that scenario you you treat you say that it's a user profile if in case i would have been using app.something then that means i'm using an app profile so basically the user profile is also going to have certain attributes or you know the objects and basic and similar is the case with the app profile they are also going to have certain attributes the only difference is that user profile corresponds to your octa environment whereas app profile corresponds to the application which is integrated with your octa environment so you know whatever attributes you have in octa you can use them using user.something and whatever attributes you have in application you can use them with app.something so all of this you know you can customize and extend it within the universal directory you can also bi-directionally map and move the attributes from octa to the applications uh you can transform attributes using a powerful and intuitive expression language before storing them in opera so i mentioned before that you know uh like for example i had i you know like if it would have required for me to you know send something which is not uh present in our opt so maybe you know i need to send maybe something like uh first maybe full name and let's suppose i do not have this attribute full name in in my offer environment so i can you know make some customizations over here like full name is basically going to be your first name and last name and i can just you know save it so basically and even if i want some you know space to be added so i can do all of that over here you know i can just save this expression and basically once this expression is saved so you see that you know something like for my id it will send before space as my you know the first name and the i mean as the full name to the application so basically or we can do all of these customizations using the octa expression language and all of the expression language you can use within the universal directory these capabilities enable you to do the following and you know you can synchronize the user profile information across cloud hr systems on-premise directory systems and applications you can provision application user accounts with rich profile information such as roles managers geo locations and other attributes that aid in configuring complex authentications and authorization rules you can collect import and store any type of user attribute including um internal externally defined customer so basically you know that's that's like a very high level or you know you could say a description of what your universal directory is all about so you know basically you can think universal directly which helps to store the users the groups which we have in october the expression language the mappings of the you know the mappings of the users to different or various applications all of these are going to be you know contained within the universal directory and hence this is very strong product of octa because with other im products like you know if i talk about ping so ping has its own directory but that's all together a different product of thing like you know you cannot use ping federated ping directly in a single environment right you need to install ping directory separately and ping federate separately so you know it requires an integration between these two products then only you can use it but with octa it's already integrated within the access management product which we see here on the cloud and you know we we can directly use it as an end required we don't require any separate integration from rn so that's the beauty of this universal directory of opta and now you know if i talk about the users and groups which we have in octa the very uh the very first two tabs which you see here in offline on the left on the left nav bar uh the people and the groups so basically you can manage users and groups or individually each one of our users whether your workflows or your customer base has a unique identity with an opera so you know like if i go to any user it has a unique identity in in on how do i identify that so whenever you click on a user right just go to the top web address url and you will see that there is an id you know which you might not understand but this id is there for router to understand and every user is going to have a unique identity so whenever the user is created in octa it's been associated with the id which is being generated by octa and whenever we correspond or we reference to this particular user in octa is always going to refer to this particular user with this particular id so that's why you know we say that you know any user created in opta has a unique identity the int lets you view and manage which apps the device can user access so you know basically if i clicked on it so octa knows this because you know it knows this particular id now you know if i am into this id i could see that you know what an app what all applications are assigned to this particular user what are groups you know are assigned to this particular user what is the profile of this particular user i could see that you know what are the attributes are populated or if i need to make a change to this you know the attributes of the profile i can go ahead and do it if in case this user has been uh you know holding any special privileges like the admin privileges so this user is actually a super administrator so i could you know go ahead and check whether okay uh what level of information is it has i can go ahead and you know edit the payment permissions and stuff like that so all of that can be done from you know directly under people tab uh this identity in addition universal directory stores unlimited amount of users and attributes from apps and sources like active directory or hr systems any type of attribute is supported including linked objects and sensitive attributes and predefined list all of it is accessible by all apps in our oin catalog over ldap or through api so our y and catalog is nothing but the octa integration network which we are going to you know discuss in detail but like for the time being you can think of it like you know any application which is being integrated that can either be integrated through your orion catalog that is your octa integration network catalog or it can be integrated you know through like custom integration whatever you can do whatever we have done you know in our previous sessions so uh now coming to how do we manage the users so you know you you could actually go to the people and you know you can manage the users you can go to the people and manage the end users in an organization so basically if you want to add a user or you know if you want to change some property of a user you just go to that user and you know you can just edit the profile of that user so all of that can be done from the people tab in octa uh adding users to the organization enables them to have the own my applications page now add and update users with just-in-time provisioning and after the very first time a user authenticates using 80 delegated authentication desktop single sign or not inbound sample so now there is an interesting concept of jit it's being often asked an interview so i'll you know just quickly discuss this topic here only so basically what happens is like you know there is a concept of jit which means like you know just in time provisioning now then now as the name suggests right it's pretty much self-explanatory like whenever it's required the account or you know anything would be provision now it depends on what what what are we asking jit to do so you know it could be account provisioning it could be user provisioning it could be application provisioning but mostly you will see that you know user provisioning that's like whenever your jet is enabled that is a just-in-time provisioning and if your application doesn't have an account yet so let's suppose for a scenario um that you know or your opt is integrated with an active directory now a new user you know joins an organization so the moment the new user joins an organization the account is created in the active directory right for that particular organization uh like that's like basically the very first uh step every organization does like the moment the on the user gets downloaded they create an account for the user in the active directory now once the account in the active directory is created and your active directory is integrated with doctor so basically what should happen is that you know that account has to flow into octa now so now there could be you know uh this would happen immediately like the moment the account is created in active directory it will flow in after that will definitely not happen so there are basically you know schedule imports so what happens is like you know account from ed to octa happens that synchronization happens but like that synchronizer happens at a certain time during the day maybe you know at 8 a.m in the morning then 12 a.m in the morning in 12 p.m in the east in the afternoon 4 p.m in the evening maybe 8 p.m in the evening and then finally one last thing at 12 so you know that's that's something being decided by the organization but like you know it doesn't mean that you know 24 hours you'll have you know every every one minute or every five minutes you'll have a sink that will actually bring those ids to opt-out now let's suppose that you know i an account was created at 8 30 a.m in the morning user has started you know his office today and the account is created in active directory but using required to access popped up but the account is yet to be scheduled or you know it will it will be flowing to octa maybe at 12 pm or you know 1 pm in the afternoon so what will employee do employee you know doesn't want to have the downtime so you know of that three or four hours where he or he or she is not able to access the environment of optic so now if your jit is enabled because your active directory is being integrated with octa and let's suppose your jit is enabled that is just in time provisioning is enabled then there could be a possibility that even if octa does not have the account of that user octa would still allow that user to get into its environment by creating the account then in there at the time of login so now let's suppose that if jet is enabled user is trying to access octa at 9 00 am in the morning account is to be scheduled or it will be flowing into octa at 12 pm let's say so at 9 00 am the author does not have that account but octa is integrated with that active directory which will bring that account into octa at 12 pm so what will happen is if jit is enabled octa is going to create an account then in there at the time when the user is trying to login so at 9am itself the account will be created within octa and uh you know the user can directly log in now there are two ways the account can be logged in i mean the user can get into the system so one of the ways that you know either octa goes to active directive delegation authentication is not allowed saying that you only authenticate this user if you find this let me know i'll allow this user i'll create an account or octa says that okay give me the permissions and you know i'll you know authenticate on your behalf so like you know either that user has to be imported manually then at that point of time and only it will allow you to then create an account if it finds an account in opta if in case that import a user option is not there and delegation is available then then in that scenario just goes to the active directory saying you only authenticate this user so or once uh active directory of the indicates and say yes it's a legitimate user the account is created with an option and that's what you know the jit is all about so it basically you know uh just eliminates your downtime of the application and it could be with any application you know let's not just talk about after let's talk about those applications which have you know business impacts if you know the users are not able to log in so if it is enabled you know it can help you increase i mean like you know reduce your downtime to a great extent so now when injected enables users usually do not receive activation emails and when using jet provisioning with daily users the procedure depends on whether delegated authentication is enabled or not so delegation is basically you know distributing your roles and responsibilities that's it so if you have delegate authentication enable you don't need to import users from ad first project provisioning to create accounts so that's what i mentioned like if your delegation is there then octa is going to go to active directory saying you only authenticate the user but if you don't have delegate authentication you need to import the ad accounts first and then it must appear in octa's imported users and then only it will happen to you know it will occur to create the account of that user in octa so i mean this second option basically doesn't serve our purpose because you know if in case we are importing users to offer then you know what's the point like you know that uh that import was supposed to happen at 12pm so if we are doing it now like that doesn't make much sense so it's better to you know go ahead with the delegation authentication and that's where jet is really strong and then you know talking about people in octa so we are basically have having the three types of people in opera so one is like the octa master users then you have directory mastered users and then finally you have the application mastered users so basically you know the apta mastered users are those users which are created in octa uh so you know they are being authenticated against the octa policy then they are being associated with the octagon groups they also provide an alternative login method separate from an external directory and they are being governed by the opera user profile so you know when when i say government or by the octagonal profile so you know there's a user profile being created in octa for every user and basically you know users which are created in opera they can be governed by the opera so you know i can go ahead and edit it but it had it been the case like this user would have been coming from ldap active directory or any other third-party source then octa cannot you know uh go ahead and do click on this edit and change the attributes it has to be done from those applications or the directories from which the user is coming from so that that's what we mean by governed by the octa user profile then if we talk about the directly so you know these users have been created in the external directory then they have been pulled into octa then you know as i mentioned that they are pulled into octa and application users are pushed into options so there's a difference between these two terms uh then you know they're being authenticated against the external directory and also they are being associated with objectives so any type of user which we have in octano uh they can be associated with octagons but if you have an ad group you cannot associate an ed group to all the users ad group can contain only 80 users can contain all that all types of users so you know basically sometimes this is a very important question being asked in the after certifications and all so just remember that you know octa groups can hold any type of users whereas ad groups can hold any type of users i mean only ad users application groups can hold only apps users they cannot hold octa users or you know in-depth users or id users in their um group then talking about the application they are being you know these users have been created with india they are pushed into optimum they have been authenticated against octa or you know the external directory and finally they are being governed by the application user so we have already you know discussed this thing uh like you know what is what do we mean by governance so like you know for a directory it has to be governed or the attributes have to be modified itself on for the application it has to be also done from the application itself i cannot go ahead and make a change over there then you know talking about the different user states or statuses what we have so you know i'll just go back to offline you know i'll just go back to people so over here you know whenever a user is created in opera you could see that you know we have got so many states here in october so we just want to discuss that particular thing so we have got you know total of eight different states available in octa and also you could see this you know you have stays pending active password lockout and suspended and finally deactivating so basically you know you have got these uh i think seven or eight you know different statuses or states what we have for the users in octa so then pending activation or provision is one of the use one of the state wherein you know the account has been created in octa but the user is not yet active so it requires some you know some kind of intervention or an action to be taken by the end user so it's usually you know when we create an account but that account like you know something like this that's winding user action something needs to be done by the user so basically you know reset the password or stuff like that or you know create enough add your credentials or i mean some personal details like your work email or maybe your phone number or alternative even something like that and then only your account is finally created and it gets active then the stage is like you know your account has been created but it is not yet active so you know you could see certain staged users over here and you could see that you know right below that stage the i mean staged um value you could see the activate also because these users are created in octa but they are not yet activated so we need to activate them and then only you they can do anything you know then active users are the users you know who are active like who have completed all their process to be onboarded in opera so you know they're working fine now then if you talk about the password reset password reset is like you know sometimes the user has to reset the password like for example uh let's suppose that the user uh there is a user or a service account which has been created by the admin and now you know there has been a temporary password being created by admin only so now that user has to you know change the password on the first login so that's where it's a password reset note like you know that uh password which has been set by the admin it's only like kind of valid for the first login and the moment the user logs in for the first time if they have to change the password so that's like your password reset logged out say it is like you know when the account has been logged out so you cannot log into octa now password expired is like you know there's an organizational policy which says that okay your password would be expired within 60 days or 90 days or 30 days whatever they you know think about it and eventually all the users who are going to be within the octa are going to abide by that policy whatever the organization has created and if the you know the for a particular use of the policy says that the password is already expired in that scenario the user has to change the password whenever they log in next so that's what the password expired state is then we have a suspended state so in this scenario users cannot log into offline receiver messages that they are indicating that indicating that they are suspended it's blocked for apps that support sample so you know basically in suspended it's more of like you know you are using an inactive account although it can be activated again but uh like you know you're temporarily inactive in an organization that's where you know your your account gets suspended then deactivated is you finally left the organization or you know you have completed your tenure with your organization that's where your account is deactivated and then finally delete it so that's what we have about people's and opt-up people here in open and next we can you know talk about a little bit of groups whatever we have in opera so basically to access the network-based service including email file service and business application every user must be authenticated and managing user access individually is time consuming and inefficient so basically you know it's trying to say that you know whatever applications we are going to integrate in our opt we need to assign users to this application now you know you can do it either giving manually permissions to those users to those application or you could create a group add all the users together and finally assign that group to the application so you know second uh method what i've just discussed that's like the best method to go ahead with it's more efficient when compared to the latter one which we discussed like giving individual permissions so that's why you know group creation actually helps us to simplify our process and you know it helps us in time consuming and it just increases our efficiency groups are important tools for identity and management systems and group data typically resides in a directory most application supports group either at the application level or within the application to specific resources now again over here we will see that you know we have got uh you know different types of grouping of so before we connect to our to the applications or other resources we can create octa we can create groups in octa or and you know we have got one group that is everyone here in octa you could see that you know if you go here and search for everyone so whatever users are going to be on board to opt for created an account automatically all those users are going to be part of this everyone group it's like a default group you cannot go ahead and change or modify this group then you have 80 groups so like you know any group coming from the application that's like a really group uh then you have ldap groups it's similar to what you have is the ad groups and then you finally have the application groups so like you know they are pretty much similar to what we just discussed for the users uh like the only difference is they have our users and now they are going to be grouped so you know any group coming from active directory they are your ad groups any group coming from your application there are app groups any good coming from build attacks that's it so you know you're going to see different different symbols for the groups being created in hong kong so you know basically right now we just have all the octagon groups we don't have anything else so you just see only octa group symbols over here if in case you are going for an active directory then in that scenario you know you will see something like this windows symbol if in case it's an application you'll see something like an app symbol over there so yeah that's what the group in octa is all about uh if we talk about the group features and you can only assign people to the octagon groups so i've mentioned before like same thing for octa users you can change their profile only for rocket users you cannot do anything with the you know ldap or led or uh directly or application is the same goes over here you can only you know add people to octa groups you cannot add people to directly ldap directory or application group if you need to add people then it has to be done from that particular application where the group is created and only all programs can be deleted no other groups can be deleted so you know talking about different different groups so you have an author group it's on octa is on cloud so you know basically your browser or the client do an https there are different groups being created for different teams and finally these groups are being assigned to different applications and then these users do sample secure web authentication or oitc to land into these applications using single sign-on then if you talk about directory groups again you have a firewall over here you again do an https to octa which is on cloud then you know there is an integration of octa with active directory so basically this ssl that is encryption and you know uh secure socket layer or https which actually helps you to you know send the groups from active directory to octa using dls security layer and once these groups are there ad groups are there in offer then again same process you can log into any application using saml secure web or ytc uh and you know you will be single signed on with it with the to these particular applications then same thing happens with the app groups you know it's pretty much the same then you know we have already mentioned that the different types of groups are octal groups and directory groups and the application groups so octagons are basically those groups which are created in normal and the membership is being managed with knockdown and directory groups are those which are created and membership is managed within the directory itself application groups are created and managed in the application now the next point is the member of our groups can be octa directly or application master use now this is an important point to understand that anyone in the uh any user any type of a user can be added to the octa group but the membership of directory would be only those users which are coming from uh active directory or ldap directory same goes for the application as well directory groups are copied into octa same application groups are also populated and if a directory instance is deactivated or deleted the associated group no longer remains active knocked out it doesn't appear in optimum and same thing happens for the application so that's what you know that's what we have regarding the people in groups here in octa uh and you know there are certain advanced features like you know going uh how do we add people how do we add you know using csv or you know there are some practicals how can we add people using apis how can we create groups how can we do group based password group how can we write group based rules and stuff like that which is all covered in the advanced training so for the fundamental parts we have understood like you know what are the different types of groups and different types of people in offline how do we manage so basically what we have seen till now is like we have gone through octa and we have understood how do we add people in octa how do we manage groups in octa how do we you know add users in octa what are the different statuses that we have in octa and now the next thing that we are going to you know study or we are going to look into is the profile editor so basically uh if i want to you know help you understand what a profile it is all about so basically uh first we need to understand the concepts of profiles what we have in october so basically in octave we have different types of user profiles so one is your octa user and the other is the app user so we have already seen this that you know there are three types of user in opera one is you know one that created an opera one which is coming from the application and the other is the one coming from the directory so basically the one which is created in opera we call that user as an octa user and the one which is coming from the application or which is you know helping us to get the attributes of an application that we call as the app user so basically the universal directory uses the concept of profiles it's a logical grouping of attributes to represent user accounts in particular universal directory supports two types of profile one is octa user profile and the other is the app user profile which we just discussed right now so these two profiles are you know types which are used to store rich attributes in octa they also help us to move rich attributes from octa to the third party application which we have already seen in case of doing saml integrations or you know oidc integrations wherein i have showed you that you know when we have to pass the user attributes from one place to another we usually use the uh octa attributes or you know octa expression language wherein you know we are using octa user profile to send or you know to read attributes of the user and then sending it to the third party applications so we use the profile editor to view or modify these profiles and from where can we see that we have to go to the directory and then go to the profile editor so here we are we are under directory and if i go to the profile editor that's where we you know land on into and over here we can see that you know all types of applications which we have in our opt so basically we have like you know different types of applications which have been integrated in octa and out of all the applications whatever the mappings we have in octa we could see in here so uh we have different types of mastered users or the groups so basically these are the users which are being created and managed by that particular source next we'll you know talk about the octa user profile so it's a logical representation of a user in octa the octa user profile is comprised of two set of attributes so basically one is the base attributes or and the other is the custom or the extensible attributes so base attributes you mean like ones which are already available from octa it's not something which you have created it's something that you know that's already being provided by octa itself and then if in case those uh default attributes or the base attributes does not suffice your requirement then octa also provides the capability of creating or you know or developing or building your own attributes so you get you know customer extensible attributes so by default octa has defined 31 base attributes for all users in an organization so you know if i go to octa application we can see that you know this is the type of octa and this is like the base or the default uh profile which we have for all the users in the octa organization over here you could see that you know we have got 31 attributes which are like base attributes you could see you know the type attribute type is base here so all of these are base attributes being provided by octane also you could see that this cross is disabled we cannot you know do anything with these set of base attributes but whenever you will see a custom attribute you can just you know have a cross or you know you can just cut those attributes the simple reason being because these are custom attributes and therefore you can add or delete or modify these attributes but the base attributes you cannot do anything with those attributes so you know these are attributes which cannot be modified or removed there are two exceptions that is first name and last name these two attributes can be marked as required or optional from aftermarket users only so over here you could see that you know you've got first name and the last name and if i click on to it right so i have the option of attribute required yes or no i can you know select it you could see right everything is disabled apart from these two things and it goes the same for the last name as well if i click on it but if in case i i go ahead and you know click on any other attribute this is also disabled for me i cannot do anything over here so you know uh basically i cannot make an attribute required or not required but with first name and last name based on the customer and based on the organization's requirement we can make it mandatory or not mandatory as for the policy which has been defined by the organization so that's how you know our attributes look like so this is basically the older version or the older ui version of octa which you know it it is this was this was the version you know it was used to look like but now octa has come up with the new version of the ui and ux changes they have done so now this is the new version how it looks like so but yeah i mean like the concept or the the logic still remains the same exactly the same in fact whatever we have discussed we still have the ability to you know define an attribute and you know check out what are all the base attributes being provided by octa then what are the octa data types so there are eight admissible data types which are being provided by octa so first of all we have a string it's a chain of zero or more unicode characters so string is something which we all know right like you know basically it can consist of it can comprise of your letters digits punctuation marks and stuff like that so it's a chain of zero or more unicode characters uh it would you know include your alpha numeric characters and stuff like that anything which can you know which you want to combine in can be considered as a string so a number it's a floating point decimal in java 64 bit double format it could also be your integer number but by default we say it as a decimal number and if we select the decimal values as 0 then it becomes an integer value so you know number and integer they are kind of same data types the only difference is one is like you know your decimal uh which contains decimal numbers which contains decimal and the integer is the one which is like you know without decimals boolean again you know it's pretty much the same as what we have in java like you know it stores the value as true and false that are the only two values allowed in the boolean data type then you have date so you know date is an important uh data type because it allows you to uh kind of stores the calendar dates and require the format of iso 8601 so that's the format which is being you know uh generally used all across the environments and you know all across the world as well so basically you can use this format for the date then you have the array of strings which is a sequential collection of strings then you have array of numbers again same thing does the difference is that that it's a sequential collection of number and same is you know array of integers again same thing sequence of something it's a collection of you know integers or numbers or what is area array is a you know uh collection of something in a sequential format so that's what you know as a definition or as the you know the as the name suggests that's what we have as the definition then we have the country code so two character country code as it is listed so you know you um basically every country has a code right like india has plus nine one uh then you have australia s plus six four then pakistan has plus nine so whatever is your country code based on that you know you will get the country code so that's what like you know it's a character uh which it's a data type which you can you know usually get from octa so these are all the different data types which we have in octa so basically what happens is like if you want to add a new attribute so you know you can define uh what type of an attribute you require and you know basically from here you can select the data type and define your attribute then we have just seen what an octa user profile is so we have understood that you know it allows us to send the attribute values from octa to third party applications now let's try to understand what is an app user profile so you know an app user profile represents a user in a third-party application directory or identity provider the app user profile let's list the third-party attributes that can that octa can read and write this profile is used to control the attributes that octa pushes to an app or the attributes imported from an app into octa so basically it's like a you know an application user profile which is there in third party application now this user profile is not there in opera this user profile is instant present in a third party application now what is a third-party application any application integrated with opera we can refer to that application as a third-party application let's refer let's say that you know we have salesforce integrated with octa so now the profile of a user within salesforce application we set that application as a third party application so now there could be a possibility that a user has its profile in salesforce so whatever attributes user is having inside salesforce we say that that is an app user profile because you know it's something the schema or you know the attributes are being defined within the application it's not defined within octa application that's why and that's the basic difference between an octa user profile or an app user profile octa also is an application but octa is not defining those attributes if octa is defining those attributes if the discipline or the schema of the attributes is within octa then we say definitely it's an authorizer profile but if the schema of the attributes is being present inside the application we see it as the app user profile it's similar to the octa user profile our app profiles have both the base attributes and the custom attributes custom attributes for the app user profiles differ from those for octa user profile whereas octa user profiles can be extended with any custom attribute app user profiles can only be extended with attributes from a predefined list that octa dynamically generates opta generates a list of attributes by querying the third party applications or directory for supported attribute so basically what is going to happen is that you know octa is going to read the third party application so it's going to query what are all the custom attributes being allowed in that application so now every application is going to have a different schema right every application cannot have a same schema like let's consider we have salesforce application and we have pagerduty application so salesforce application is going to have a different set of schema whereas pagerduty application is going to have a different set of schema so now these two applications cannot have same set of schema but how will octa come to know right so octa has to query these applications and it will come to know okay what are all these supported attributes in these applications let's say that salesforce suppose uh supports kind of 10 to 15 custom attributes only whereas pagerduty supports 20 to 25 customer attributes so octa has to make that you know uh has to have that understanding what are all the custom attributes being supported by on the application and accordingly it allows you to create the custom applications and opt for that particular app user profile so that's you know that's the basic difference between an octa user profile and the app user profile now you know if i just have to give you a quick overview of how it looks like so basically you know you can see that this is opta so you know this you will just get to see just one application these are all you know your applications so you know these are all dummy applications which i have created but if in case i go ahead and you know look ahead and look into mappings so these are all the attributes being you know sent from application to octa so you know we can send you you can you know map anything if in case the attribute exists inside of inside that application this pranjal hyphen sales force if the application attribute exists then i can you know refer to that attribute maybe like app.firstname i'm mapping the tab.first name to my octa username and if in case the mapping has to be reversed like if it is going from octa to pranjar sales for the application then you know i can just uh kind of you know add attributes or do the mapping over here and then finally save the mapping so it allows us to do both kind of mappings that is from app to october to app and that depends on us so you know you have apps then you have directories you know if in case you have different directories being integrated like your active directory all the ldap directory then in that scenario you you can have the mapping being you know done here and also if you have identity providers although 99 of the times you are going to see that opt is going to act as your identity provider but in some scenarios like you might have you know maybe linkedin or you know maybe google who are being who are being you know integrated with your opera as the identity provider in that scenario octa doesn't act as your identity provider in fact octa act as a service provider leveraging you to helping you to leverage octa services like you know if in case some single sign-on application has been integrated with octa so now octa is giving permission to the end user that you get authenticated by google and you can leverage the application which i have under me so you know that's like after acting as a service provider instead of acting as the identity provider so that's that's pretty much it about what we have under profile editor then you know if in case we want to understand a little bit on mapping so uh we have profile mappings which allows the administrators to precisely control the attributes exchanged during the provisioning process for a list of apps that integrate particularly well with universal directory we have apps supporting profile mapping the two chief use cases that universal directory facilitates our app to octa and then octa to app just now we saw that thing that you know we have application to octa mapping and octa to application mapping in the very first case we have application to opt out organizations typically use a source of truth apps such as a directory or the human resources system and some organizations might have several sources of growth mappings define how attributes on these various sources are imported into octa user profile so map what are mappings right so mapping is something that you are telling okay i have this attribute value in this particular application and i am mapping or sending this particular value to this particular attribute in your application so you know whenever there is a two-party or a two-way communication and information has to be exchanged so there has to be some mapping right like what information should be exchanged with what attribute in which application is something you know we define under mappings so that's what mapping helps you to do so you know if you talk about mappings app to octa so basically this is your application these are your two different applications and now you know you are just mapping it to the octa so your first name and last name is coming from active directory your manager details or your boss information is coming from workday and finally all of this information is being stored in octa so octa apps is a single source software and the mapping is from different different applications you can have reverse mapping that is from octa to app in the second use case organizations want to propagate the data in octa to other applications to provision accounts and update accounts with rich data this is possible if the octa user profile has rich attributes and the app in octa supports provisioning so you know you know now the concept of provisioning is very important why do we do this kind of a mapping is like you know we are expecting that new users whosoever are coming they would be getting their attribute values from up top so now in order to create new users in right inside the application we require that software should support provisioning for that application now if octa itself is not allowing that i mean is not allowing the creation of that new user how will octa send the attribute values for that new user right so that's why we have of coin connectors wherein octa you know octa actually uh supports the provisioning concept wherein you know you you have some oin which we are going to discuss in our next session but oin is a octa integration network and these are like having default provisioning connectors available you can still have you know in case like the default connector doesn't support you can still go ahead with the skin provisioning if you are doing a samal integration if you are doing oidc then we cannot do provisioning and octa octa doesn't support any provisioning for oidc app but if in case you are doing saml integration in those scenario you can do skin provisioning even if you have done a custom integration so octa should support provisioning if octa is supporting provisioning then in that scenario octa to application mapping makes sense so you know doctor would be sending some last name attribute value first name attribute value boss value and that and all would be finally be created inside the application with the same value which octa is saying so you know that mapping makes sense we have you know little bit discussed about this using expressions now we will you know discuss a little bit more about what do we have expressions i have told you that you know uh we use expressions in order to send data uh and whenever we are using octa user profile in that those scenarios we usually use expressions so expressions within the mapping lets you modify attributes before they are stored in octals into apps they allow you to concatenate attributes manipulate string convert data types and many more things octa supports a subset of the spring expression language function so basically what does it mean is that you know if i just go to the exam i mean if i just go to the application where we were you know trying to send certain attributes in octa right uh this was the place wherein you know we were trying to send certain attributes now one of the best example to see is this particular attribute only over here we are trying to concatenate two different things we don't have any attribute in octave which directly gives us the full name but we have attributes and object which it gives individually the first name and individually the last name and as for the logic says we just need to combine these two names to you know get the full name so all of these you know data transformation and stuff can be done through octa expression language let's suppose that you know you have an email id like test at the rate abc.com but you just required to extract something just before at the rate you know whatever string value you have before at the rate you just require that you don't want you know the value to be returned after at the rate in your email id so you know you can do all those data transformations and basically it is using java spring language so you know all the substring function concatenate function or you know trim functions whatever we have these you know functions in java all of those will work over here so while some functions work in other areas of the product so all the functions do not do i mean like i just mentioned that some of them should work but all of them will not work like substring works uh then concatenate works then trim works but like all of them doesn't work like you know if you if you think like let's go ahead and put some for else and you know if else for switch all of these functions doesn't work so expressions are useful for maintaining data integrity and formats across apps for example you might wish to use an email prefix as a username but replace an email suffix or populate attributes based on the compilation of existing ones so you know this is our display name let's suppose you want to display it in like you know like the last name comma first name so you can definitely do it via uh like you know this expression language so and you know the other thing we just discussed right now like if in case you just want you have an email and you want something only to be extracted before at the rate so you can do it using expression languages so all of this you know whatever we see here this is all an expression language like source.firstname user.class name and stuff like that so that's what you know that's what we understood over here and that's what we have under directory sections uh we also have a self registration or a self service registration tab over here uh you know which just allows you to uh like show you that whenever you try to do a registration uh you will be able to see these attributes over here and you know what will happen post registration so whenever a new user gets into octa so they you know will be having these set of attributes which they have to fill in and you know basically once they register on the form they would be you know ask to verify their email address and finally they will be redirected to the opera user dashboard so that's something that you know we can manage it from the cell service registration of new users coming into octa uh also we have a directory integration tab also although it's it is usually covered in the advanced uh training of octa but if i just have to brief you right uh like many times in this fundamental course also i have mentioned that you know when directories are integrated when active directory is integrated or ldap directory is integrated from where are those directories getting integrated this is the place to you know uh integrate a directory in optim so if in case you have an active directory external microsoft windows active directory and you want to integrate that so you know you go here and you know you have two options to integrate you can do an active directory integration or an ldap directory integration so you know basically once your directory is integrated and whatever groups or ous you are sending from the your directory to the application which we have the option to select from octa itself once the directory is integrated you get all the users whatever you have in active directory and you know this is like one of the major things done in most of the organization uh because 99 of the organizations have active directory or the ldap directories and they are and if they have octa environment so definitely you know uh they go ahead and do integrations with those directory and this is a very important topic being asked in many interviews like you know based on directory integrations if somebody has performed so this is basically covered in our advanced course of octa but uh just to give an overview of what directory integration says so it just allows you to import people from different uh or existing sources which are you know there in the environment but not in office so users need to integrate with offline or to get all those people then finally you have profile sources currently since we don't have any directory integrated hence we do not see anything over here but if in case we have you know more than one active directory or one that more than one ldap directory or multiple active directory or multiple ldap directories being integrated then we would be able to see all those active directories or ldap directories over here and then we can define the order of those directories like you know which directory should be given the preference or you know or what should be the profile so so it's kind of a profile master it's an application that acts as a source of truth for user profile attributes a user can only be sourced by a single application or a directory at a time and the priority determines which application or directory is considered the profile source for the user who is assigned to multiple profile applications or directly so let's suppose there is a user who has been tagged or assigned to multiple directories and which directory is going to define the attribute or which directory would master or you know would be the first source of uh would be the profile master of that particular user so based on the priority whichever directory is on the top that directory would be you know actually defining the uh attribute of the user so that's that's what you know the profile sources are all about currently we don't have any profile sources in our environment hence we do not see it but once we integrate different directories in our system we would be able to see them and then you know accordingly we can just change the position of those attributes so yeah i mean that's uh that's pretty much it and uh we'll just cover this particular thing in this particular class so you know we have inclu we have covered what directory is all about we have understood people in groups now we have understood the profile data directly integration self-service and profile sources next we are you know going to talk mostly under the security tab this is again a very important app so i'll try to you know cover most of the fundamental parts on the security tab and then we'll take it from there so basically uh what we have covered till now is like you know we have seen this directory tab we we worked around you know we have seen a little bit of water how do we add people in octa or you know how what are the different ways to add people in octa then we also saw that what are the different groups which we can have in octa like the active directory groups application groups the octa groups we went through the profile editor understanding what is the meaning of profile editor and why do we require it in octa then directory integrations was one of the most important topics which i mentioned last time that it's been asked in interviews a lot so this was one thing which we haven't seen it practically but like fundamentally we have understood that you know what are direct integrations and you know what is the purpose of doing directory indications then we also saw the self-service registration page wherein you know uh we have a little bit of knowledge of you know why do we require it when configurational changes we can do from this particular sales registration page and then we finally went through the profile sources wherein we saw that if we have different applications or different directories integrated with octa in that scenario we can you know see those directories of different apps uh in the profile sources from wherever the profile we are receiving the profile we can see them in the profile sources and also we can decide the priority of these profile resources so that's what you know we had under the directory tab so this is one of the more this is like one of the important apps under octa which we should understand and then another second i mean this is the most important app to be honest which we have under the admin console that is security tab uh i mean dashboards and customizations are something they are like you know they have been like customization especially is being newly introduced by opta so basically it is not covered a lot under fundamentally because like you know a lot of customizations are required sometimes on the octagon so we can you know go through the customization step but from fundamental point of view it's not very important but uh from advanced software training point of view yes it is important so we'll although you know we'll start with the security tab today and uh you know once we we are covered with this topic uh we'll go through this customization tabs and you know short and we'll see that what are the different types of customizations which octa allows us to do but for the time being we'll you know stick ourselves to the security tab so under security we can see right uh that we have many other topics or many other sub topics we could say uh so under security we have a general we have health insights then authentication multi-factor identity provider delegated authentication networks behavior detection administrator api and impaired opens so one by one we'll go through each one of them uh there would be a little bit of theoretical part there little bit of you know i'll use the octa environment itself to help you explain so we'll start off with the very first topic that is a general so as i've opened the general tab so you could see that you know there are some general configuration settings which you can uh uh you can you know configure in octa which includes like you know some if you want to have new sign on notification email so like you know whenever a user is getting into the uh is getting onboarded in octa do you want the end users to be notified with an email if yes then make it enable if notes and make it disabled then if users are you know changing their passwords or stuff like that then they should be uh you know triggered with an email so i have kept it disabled but most of the times you'll see that you know this is enabled for most of the organizations then mfa enrolled notification email is disabled or not so you know when a person is getting enrolled for an mfa whether the person should be sent a notification email or not a reset notification email when the mfa has been reset again then at that point of time whether the user should be you know sent with a notification email or not then report suspicious activity via email so there are a lot of time that you know for a particular user in octa because octa use a little bit of intelligence on the system to you know identify which user is you know kind of a suspicious user and which is a legitimate user now think of a scenario wherein you know you have a user id and password but you yourself is not trying to log into the environment but instead someone else is trying to login with your id and he or she doesn't know your password uh he or she knows your username but doesn't know your password so at that point of time that user might be you know that hacker or you know that malicious or the suspicious person could be again and again trying with different sets of passwords he might think you have it and you know at that point of time octa would actually identify whether this is a suspicious user or not so at that point of time you know if there are a lot of unsuccessful login attempts so afterward automatically you know send those emails to the end user saying that you know someone is trying to get into the system is it you or not so something like that so this allows the users to report activities they do not recognize from email notifications so generally this is enabled in all the organizations then uh from an organization prospective we have like you know remember me check box on sign in so basically like you know if you are trying to uh log into octa using your normal browser i mean normal browser window not an incognito not a private window but just a normal window so in that scenario you get an option to you know uh like remember me so basically if you check box that thing so you know the browser saves or you know your account gets saved in the browser cache and basically next time when you log into the environment you don't have to log in again instead you know because you have a session already created with browser you it will automatically log you in in the normal windows this will not happen in incognito windows but with normal windows yes it will happen so basically you know we can make it disabled although because it's never a good practice to you know go ahead and enable it because users are usually they don't want to enter their username and password again and again which is not a good practice to be honest because like if you have your browser uh session always there and you know you don't have to login in that snare it's a little bit of control it is it's a little bit of security breach the simple reason being because if your system is hacked you know you're all the applications with which your browser is logged in that is also hacked so that's definitely you know not not supportive and not not recommended at all then activation emails are valid for seven days basically whenever you get the activation emails right uh like for example you are uh whenever a user is onboarded to octa you know from a network perspective yeah we trigger the activation emails to the user in order to set their password and you know in order to reset their password so those activation emails are being you know valid for seven days we can make it to one hour two or four hours eight hours one day and you know these are all the drop down options which we have we cannot customize it as you can see that there is no option i can you know add it on my own like if i wanted to be maybe at 16 hours it doesn't allow me that either i can have eight hours or one day so basically whatever options software gives we can you know have that i can make it valid for 30 days i can change it but i cannot you know add my own option so that's a limitation which octa comes up with but that's fine like you know they are still giving us a lot of options which you know we can pick and choose and accordingly decide what our organization wants to have this policy for then enforce device binding for creating sessions so basically this is again a same thing like you know uh so you can have the device bindings for creating the sessions and what this uh actually means is that you know uh for example you are being uh logged in with a particular device you have a particular laptop and you are being logged in with that laptop so you don't have to log in again and again uh so this is something like you know i mentioned about like the browser cache because you know you have logged in with that browser with your certain id maybe or you know work id or something and now you have a session created you don't have to log in again so same thing happens like you know if you're logged into the device maybe if you're logged in with your phone so you don't have to log in again and again right like device binding is there for all the applications like facebook instagram you are not logging into these applications every day right you have a device and from which there is an application you have installed you have logged in once and now you are logged in forever so that's what happens like you know uh you can have uh device binding for creating sessions but that's again not the recommended approach for the opera because octa is mostly used on the web versions instead it is not you know um like you won't see much use of octa on your mobile phones so basically anything on web it's not recommended that you know you create sessions or you know you have that cachet stored in your browser which has a lot of confidential data so yeah that's like now we have octa mobile so basically you know it's pretty much talking about the octa device or the octa application of the phone so basically you have a sign-on feature which in which you can ask for pin whether a user is an actor for 10 minutes spin expires or not you know you can choose after how much time the pin would expire and all and all and you have to extension for ios apps so it allows the app extension for ios safari to sign on to the saml apps so basically safari is a ios you know browser that's where we have this extension and then you have octa thread inside settings so basically authentication request from ips exhibiting suspicious behavior that suggests malicious activity can be logged in the system law they can be rate limited or blocked based on threat level and whenever you know we can you know over here choose uh if in case there is any threat activity being discovered by octo or being detected by optum what do we have to do either we don't have to take any action or we log in authentication attempts from the malicious ips and basically or we have the option to you know log in and for security based on threat level and then we have zones which we are going to cover when we will talk about the networks over here but zones are you know specific places wherein you know regional places which are being divided or segregated all over the world in order to you know uh understand what are the ips belonging to that particular reason so you know you can exempt zones from here so these are some of the general settings which we have under you know octa or under security tab of octa uh next you know we'll quickly go through the health insights once we'll see you know what what does this health insight helps us to understand uh or you know helps us in an after from security point of view so basically you know in health insects you'll see a lot of incomplete then you'll see complete and then finally dismissed so over here you know you will see that one of the security impacts which is critical is because is that you know it's saying that you have more than 75 percent admin who have super admin privileges now if i go to admin right so i could see that you know i have a lot of admins which are you know super admins you can see all of them are impact super admins so that's never a good practice actually uh you know we should have limited number of people as a super admin because right now what this organization have is like if it has around 20 people out of those 10 or 15 people are super admin now to manage 20 users we don't require 15 super admins okay we just require maybe one or two super admin users to manage all those 20 and if you're talking about uh large organizations which around like you know one lap of users in those scenarios we require a team of super admin users which could be you know somewhere around five to seven or seven to ten uh not more than you know 10 to 15 in super admin users but uh you know right now i'm having more than 75 percent of my users who are super admin so like if in case i have 20 users so that means at least 15 or more users are super admin users which is definitely you know not recommended at all so that's why this is a critical you know security impact the reason being because now uh anyone in your organization suppose i have an organization with 20 people in my organization and if i give everyone the super admin privileges so you know anyone can do anything like then why do we have a different level of roles or you know permissions or administrative rights when everyone is to you know get the highest level of privileges so that's why you know like people should be given access as per their role or you know ask for their uh job profile but they shouldn't be given a complete level of access when they're not responsible for doing that i mean like you know uh there could be many people here in octave which does not require to have you know complete super advanced privileges so we do not need to give them we can just you know create them a simple end user if even if they require something based on you know their role and stuff so we can you know create a custom role you know based on their role if they're an application and we can make them an app admin if they are a group admin we can make them a group admin and stuff like that then threat insights has not been unable to block suspicious eyepiece so basically we haven't enabled the threat insights over here and of course in order to you know block the suspicious ips which is again you know a kind of a security risk and that's why it shows us critical then we have password change notifications we have disabled so these are all incomplete you know health insights after is kind of you know going to uh going to you know uh show you what are all the you know things which you should do in order to make your environment more uh you know uh securable but if in case you don't you know want to follow it then it's your wish then it comes as an incompleted task but if in case you feel that you don't know this should be done then you know i can just go to go over here and maybe let's keep this as enabled and then save it and now let's go back to the health insights so you'll see that that particular factor which was coming is gone and now this is something from 43 percent to 50 percent so as an octa developer or as an octa administrator especially you should you know see all these recommendations which proctor is giving it's part of a live audit being done by octa it's you know reading your environment uh on that particular moment and it is suggesting you what changes you should do in order to you know make it more secure so you should definitely follow the changes or the recommendations being divided by octa under health insights and if in case you feel that you know you this like for example uh but i have an organizational policy in which i have 20 members but out of those 15 has to be super advanced and i you know cannot do anything so i can just you know leave it then in that scenario i don't have to take an action it's not necessary that i have to take an action on every recommendation being provided by octa but always a good practice to take an action on the recommendations provided by so basically you know whatever the other recommendations we should just you know go through it and what are the completed recommendations we have done or what are all the dismissed you know we you can just you know maybe dismiss some of the recommendations suppose and this is the one i feel that you know i am not never going to change so i can just you know go ahead and dismiss it so basically my task is completed now uh so you know my percentage is increasing and now this would be coming under the distance class i can you know even if in case like later on i change my mind that you know i know i can you know go ahead and make it make this recommendation work out in that scenario i'll just undo it but uh otherwise you know i can just dismiss all of them and if in case i just dismiss all of them my you know percentage would just keep on increasing so you know you'll see that now it's 78 and then finally it will be 100 so basically you know i have dismissed a lot of tasks and that's why i don't see anything but uh that's like you know something based on your requirement based on your organizational policies you have to decide what action you have to take and on it so that's pretty much your you know health inside feature under security tab and next we have the authentication tab and this is again a very important you know tab for us to understand a lot of authentication policies are being written in octa under authentication tab so it's important for us to understand what does this tab means and you know how do we play around with this tab so you'll see that you know you have authentication over here and you know you have the ability to create on you know add a new password policy now why do we require this you know why do we require this tab so and when do we you know have this tab active so basically whenever the users are getting logged into octa right whenever a user is trying to get into octa at that point of time when the user enters the credentials that is their username and password and when they click on submit that's when this you know authentication tab in octa comes into picture or so whatever you write over here that will be implemented at that point of time the event would be when you are you know kind of entering your credentials and hitting on enter that at that point of time these policies or you know these rules would be triggered so uh under authentication we have got couple of you know categories one is the password and the other is the sign on so basically uh because we are talking about octa right and if you are talking about security so password is one of the most important things for us to you know uh help us save uh from security point of view uh you know any any hacker you know any hacker trying to get into your account they require your password not just password today now because you know we have multi factors of authentication like two level three levels so they might require other things as well but the very first factor for every organization for every account you have or any application it requires a password right so it's very you know a very basic and a very important thing for us to understand you know what level of password of what complexity of password we should have in order to you know uh get ourselves safe from all these outside world attacks so uh basically you if i come over here i have the option of password and a sign on i have the option to you know add a new password policy under password policy you could see that you know you have password settings wherein you know you could say that a minimum length of my password has to be whatever num you know the number of characters you decide i decided then you know whether it has to have a lower case it has to have an upper case a number a symbol you know it should not contain your first name it should not contain your last name it should not contain your username and then restrict use of common password like test enter it one two three your maybe your name at the rate one two three uh or maybe password at the rate one two three something like that so these are all very common passwords being used by many of the users and you know hackers can easily guess these passwords and get into the system so you know we don't have to use these common passwords even if we are using it octa has its own you know list octa will check or query that list if the password which has been entered by the user is something you know which is already which is a common password if it is then it will not allow you if you will checkbox this if you will check this box then a minimum password is just like you know you can decide how many days minimum password ages then password expires after how many days and then you know you can just prompt the user before some particular days that your password is going to expire so that the user can change it on time then after unsuccessful login the malicious activity i was talking about right like you have the username but you don't know the password so you're again and again trying to enter into your system with some nonsense password which is not the correct one so in that scenario we can you know write a password policies that if there has been already more than 10 unsuccessful attempts just lock the account dot allow the user now don't allow the actual user as well to you know get into the system because system doesn't know whether it's an actual user or like you know so the account would be and that has to be unlocked by the administrator but like if someone has already uh given 10 attempts and they all have been unsuccessful then that means like you know account has to be locked and it happens with you know everywhere if you go to sbi website over there also you get an option to you know just put your credentials in what time you put it in correct your account is locked and even on iphones like you know again and again you're trying to enter your site i mean your password which is not correct and you know maybe five or ten times then your account is locked for like 15 minutes you cannot use the system then so so that you know that's like a general policy being implemented everywhere you'll see and also allow all these general policies then account is automatically unlocked if the account is locked we can decide like you know for sbi it's like the amount is unlocked after one day uh for you know for the iphone it's like after 15 minutes it will be unlocked so basically we can decide when the account should be unlocked and show lockout failures and send lockout emails to the user so basically once their account is locked you can just send them the emails then there is account recovery option also for example you have you know forgotten your password so now how do you you know get back into your account so you know you have the option either to go through it by an email or you know through sms also if i check this sms then you have the option to go through it by sms also and we can just you know have those emails or sms being sent valid for like one hour so you know if in case we want to increase we can do that and password recovery complex question complexity is fourth character so basically whatever are the recovery equations that you have said that has to have minimum four characters to it if in case they don't have it you would allow it so we can just you know go ahead and create a policy once we create a policy we could see that you know something like this we have got you know some test password policies so you could see that you know there are being policies being created over here now you know you can just go ahead and activate the policy or deactivate the policy or edit the policy if you have already created so basically you know this is how you create a password policy here in octa and the other important thing which you could see is like you know you have numbers over here one two three four so that means like you know number one is like the highest priority so this would be the very first policy that would be implemented uh whenever you know we are talking about the authentication tabs and all and also we will understand you know to which set of users this is going to be implemented so basically this has been assigned to the admin group now a user who is part of this admin group so this would be the first policy that would be implemented for them if the user is part of other groups as well and if the user is not part of this group and some other group then you know this policy would be implemented but you'll see that you know both of them are you know are having the same assigned to group so if the person is a part of this group so definitely this policy would be implemented and then this policy would be implemented and then this policy now if someone who is a part of everyone group but not a part of admin group so in that scenario policy third three or you know this test password policy would be implemented on them because the very first two they are not the audience for whom we want to you know apply this policy so that's a very good feature which we have like you know we could have different password policies being cared for different people like for end users we could have you know uh some set of policies for admins we could have different uh for finance because it's like you know a lot of confidential or restricted information over there we could have a different set of policy for finance team and all so basically we based on different teams or the groups we can have different policies password policies created so that's how we create a password policy now we'll move on to the sign on policy so basically sign on policies again you know uh if i just go ahead and you know see it so i can just you know go ahead and decide what would be my policy name and to which set of people it will be assigned so like you know i have created two policies one policy if i don't create anything so i by default i have a policy created by octa itself if indeed i create something then in you know i can decide to whom it has to be applied so right now i've kept it as everyone i can you know kept it as admin group or anything like you know i can just update the policy so now the set of policy will only be applied to the people who are present in this group now once i create a policy over here i have to add a rule and unless i don't add a rule that policy doesn't make any sense because you know eventually what this policy is going to do is something you will define in a rule so you can have multiple rules for a single policy it's not necessary that you can have just one rule that's why we have this hierarchy that you create a policy and then you assign a rule to it so you could see that you know uh you have a rule name you can decide what if you want to exclude certain users from this particular use and you know if you can check you can see that if a user's hyphen is somewhere in zone not in zone anywhere and authenticate via like you know something then you can deselect the behavior the risk type then access is allowed or not and then prompt for mfa and stuff like that so maybe in case i say allowed and then prompt for them so like now mfa would be prompted now you can say that it's per device every time or you know per session then if it is a per session you need to give them what is the factor like thing how much time after the session expires and then you can finally create a rule so there are different set of rules being created over here and you know once these rules are these policies are being created at that point of time you could see that you know um whenever the user is trying to get into it these you know these policies are being implemented at that point of time these policies run and you know whatever you have written over here that would make sense to the end user so that's what you you know you have under authentication policies uh next we'll see you know uh we'll go through multifactor one so we'll see what are the different octa mfa support provided so we have octa verify we have authentication sms or we could you know directly see from here as well so we have octa verify we have sms authentication we have google authentication fee to web authentication symantec vip on-premise mfa rsa secure id and email authentication so out of these whatever you see as green text so these are being already configured here in our environment that doesn't mean that these cannot be configured we can configure all these as well but like in our test environment we don't have the you know ability to do that like on-premise mfa means that you you require a chip or certain thing which you'll be entering in your system and then only you'll be able to do it so you know we cannot um go ahead and activate this i mean we can activate it but like this will not make any sense for us so if i even if i'm trying to activate this is not getting activated then you know all these things actually require so this is activated now semantics we require you know our users must install vip access app on their mobile phone so you know this is a requirement for it uh again we can activate feed or do uh this is not possible because like this is you know an optimized thing so that's why it's not possible we can also not activate the rss secure id so yeah so basically you know we can activate all these factors and now this is once these factors are you know uh kind of configured uh you can you know add multi-factor policies over here same as that you have configured authentication policy you will first create an mfa policies and then you know you will create a rule in order to create an mfp policy so now we'll understand we have gone through the multi multi-factors now we will see the identity providers so basically we have you know we have this concept of adding identity providers here in octa now why do we add identity providers is because that you know if in case you 99 of the times you will see that you know octa would be acting as your identity provider uh because you know you octa would be the one holding all the identities with it uh you know coming from different applications or directories or you know the users being created in octa directory itself but you know sometimes it's required that you know you want to add different like you know maybe social platforms as your identity provider and you know you want to leave raise the services of what like when i say leverage the services so there could be a possibility that you have an application integrated with opta and now you want to go to that application using maybe you know you want to like log into gmail and then directly use the application which is integrated with doctor in that scenario you have to you know bring in gmail or you know google as your identity provider you know so now if i you know go ahead and add identity provider i could see the list of all those applications which are being supported as an identity provider with doctor i can you know add any of these identity providers with octa i could see that [Music] um oh so basically i could see that you know i have different set of applications which are being uh providing me idp so i can add amazon idp apple idp discord idp facebook idp github gitlab on google idp linked linkedin idp microsoft open id connect paypal saml 2.0 salesforce450 and yahoo and yahoo japan so these are all you know these set of applications uh or the identity providers with which i can you know go ahead and configure in my system if i just choose with google so there are you know a certain settings which i have to perform in order to set this you know identity provider with google which you know is covered obviously under advanced section uh we do not cover you know identity providers under a fundamental section but uh basically the concept of identity provider is that you know now your google if you added google as your identity provider so basically google is going to you know authenticate the identity checking its own database and if google says yes that it's a legitimate user allow this user we are going to directly use opta services uh i mean that octa's applications which are integrated and you know we will directly land into of the and we'll just you know move to those or we'll we redirect to those applications to which we want to get into so it's a practical lab which you know which we haven't covered in our advanced section but for the time being we'll understand that you know the identity providers is something in which your octa is going to act as the service provider and the third party identity provider which you are configuring is going to act as your identity provider so you also have routing rules over here which you can add and you know which you can uh definitely support i mean you can add a routing rule over here there is a default rule created so you can see that you know if there is a user's ips coming from anywhere and the device platform is any device i can you know go ahead and choose the devices like ios or android but right now i'm saying it's in any device and the user is accessing any application and user matches anything then use this identity provider which is opt up and over here we already have that one identity provider which is this particular developer registration so this is an octa idp and that's how octa uses that's how octa becomes an idb everywhere right now but like if i add you know my own uh identity provider in that scenario i can create a rule in which i could say that you know basically if in case like you know user's ip is coming anywhere and your user matches this application then use this identity provider which would be something else which i have you know added as an id provider so that's basically our identity providers here under the security tab next we have the delegated authentication so basically delegated authentication is usually you know same concept which we have discovered or which we have discussed the under directory directory integration tabs we required a delegated authentication is because what is delegation delegation is basically you know distributing your responsibilities or you know segregating your work into different different uh hubs so basically like you know if in case like octa is integrated with the active directory and there is an 80 delegation provided so we discuss the concept of jit that is just in time provisioning in that scenario delegation comes in very handy where you know octa tells an active directory or the ldap directory that you go ahead and authenticate the identities based on your you know database so that's what delegated authentication is all about we have already discussed the same like now if we want to configure an active directory i just you know land onto that same directory integration type we could see here right so it's exactly the same what we have discussed before so you know there is nothing much to delegate authentication next we have the network zones so basically i'll you know use a little bit of theoretical session to understand what our network zone so basically we have the network zone is the security parameters used to limit or restrict access to a network based on a single ip address one or more ip address range or a list of jio locations network zones are defined and maintained by admins who wish to improve and strengthen network security for their organization and users to access network zone navigate to security and networks from the admin console so basically if i you know go here i'm into security and then i can just go to network so basically what is the zone it's a security parameter used to limit or restrict access to a network based on a single ip address or more ip addresses or you know a list of geo locations so based on like you know ib address or geo locations i can you know restrict a zone or a region wherein you know um access will be only provided to that particular zone so they have been defined and maintained by admins who wish to improve and stand in the network security for their organization and users uh network zone consists of two types of zones the one is the one are the ib zones and the other dynamic zones network zones may be incorporated into policies application sign-on rules vpn notifications and integrated windows authentication policies and rules are updated automatically when a zone definition is modified and there may be 100 zones which may be configured in octa so there can be you know up to 100 zones you can configure different types of zones in opera each zone may contain 150 gateway ips 150 proxy ips so you know basically over here if i come you can you know add two types of zone one is the dynamic zone and under this you have the gateway and the proxy ip so you can add up to 150 gateway 150 uh proxy ips so yeah and ib blacklist zone may contain up to 1000 gateways per zone and up to a total of 25 000 per organization so basically we discuss about two types of zones so one is the ip zone it is a type of zone where the network parameter is defined by the eyepiece and the dynamic zone is the type of zone where the network parameter is defined by either the ip or the geolocation so you know that's how we define the zones then we have the dynamic zone so under dynamic zone we can either define the geo location for a dynamic zone if the geo location for the network zone feature is enabled we can use the geology geographical specifications when configuring the zone so you know if in case i go ahead and want to configure the you know uh zone so i can you know based on the locations maybe i want to do it for india i can you know add it and then you know under india i can decide which state may be the long enough or maybe you know i can decide okay with state uttarakhand anything you know i can just add these uh over here then uh so then we have autonomous system numbers for a dynamic zone they are used to uniquely identify each network on the internet isps which is identity service and internet service providers can apply to obtain one or more asns assigned to them while in ispc name can change their assigned asn is reserved and immutable so we have autonomous system numbers for a dynamic zone which are used to uniquely identify each network on the internet so there would be you know many internet networks on the internet with certain names and some you know unique id which will help them identify which network it is so this these numbers actually helps us to you know from these numbers actually helps us to identify from which network they are coming on internet so even if the name changes asm doesn't change so you know we kind of have internet service provider can have their name change but they won't have their asm change that is your autonomous system number uh this feature enables a sense for dynamic zone configurations once configured a dynamic zone for the essence may then be included as part of sign on policies empty policies app signed on policies app vpn notification settings or idp routing rules so whatever we have seen that now right like mfa policies authentication policies uh application policies the routing rules and identity provider all of it can be you know we can use this asn's over there as well to write different types of policies then define ip types for their dynamic zone the ip type setting checks and determines if a client uses the proxy and the type of proxy is one if one is identified the following settings are available to define an ipv for a dynamic zone we can use any we can use any proxy we can use store anonymizer proxy and not store anonymizer proxy so basically any means you can ignore all the proxy types if selected at least one of the following must be defined that is your location um then any proxy considers clients that uses a tor anonymizer proxy or a non-dollar anonymizer proxy type tor anonymizer proxy will only consider those trends which uses it and non-thought would only consider those things it doesn't use that so that's pretty much it about our network you know network zones it's again you know something to see on more on practical but fundamentally fundamentally we have covered what all theory part we have under network zones uh we can you know see a little bit of practical thing of what we have just seen we already have just discussed it now in our advanced training uh then next thing which we have is the behavior detection now this is again you know a very important thing for us to understand there are different types of behaviors which can be detected in octa based on you know different factors you have the location ib device and velocity with which you know you can define a behavior of an of an individual or an or a person and you know based on this behavior uh there are basically actions being taken in octa so you know you can write a behavior addiction or add a behavior detection and you know you could see there are certain behavior detections being added over here uh where you know you have given a name to it you have decided what type of behavior it is and eventually that you know you have a kind of written a policy or a rule that you know if the location grenade is city then evaluate against the authentication which means that you know uh basically if the city of the user is getting changed again and again maybe like you know uh within 20 authentication the base uh the city has seen so automatically the behavior of that user would be directed and it would take an action upon it so you know uh if the country is getting changed off the user like today i'm in us the next day i'm in india then third time in pakistan somewhere in nepal so that behavior would be detected by oprah and you know it would be if in case after feels that this is a malicious or a suspicious behavior in that scenario you know actions would be taken so that's what hackers do like you know they'll see that uh they're currently sitting in south africa and once they are one someone is trying to track them their you know ipa changes from south africa to new york from new york to japan japan to china that's how you know they keep on fluctuating their ip range and they keep on making the fool of the person who is trying to you know uh track them so that's why you know octa has this behavior detection which whenever the you know location or you know the device or the city or you know a velocity is changing i will detect that behavior and it will automatically you know take action upon it and also you could see that you know we can define this set of authentications like the number of authentications at which they would be you know uh making uh i mean octa would be taking an action on uh so basically you know if in case i am in a new geo location which means that you know my latitude and longitude should have a distance of at least 20 kilometers so in that state i would say that you know i would consider that as a new geo location um but i could you know still go ahead and change that like you know from 20 kilometers to maybe 100 kilometers or 1000 kilometers uh that is something based on the organizational policy but the important thing for us to understand is that we we should add the behaviors over here in order for octa to understand whether it's a malicious user or not a malicious user so that's all what we have under behavior detection next we have the administrators tab so under adwords status we have you know different types of administrators we have the option to add admin status and also you know i have one people a slide where you know we can see what are the different types of administrators so we have a super admin administrator which has the highest level of privileges in octa it has you know got all the tasks and permission sets in octa then we have an org admin who can you know do most of the things being done by the super admin but can uh they can you know uh they can perform most of the or white settings can perform all the management tasks for users groups and mobile policies and devices they cannot perform any application management tasks so that's the difference between a super and all and argument is the second highest level of privileges we have an offer then you can have a user admin who can create and you add users deactivate users reset passwords they can also add be used to restrict their tasks to a selector group or groups of octa user then you have app users admin then who can run reports and manage profile information they can also view users and groups but not modify either and they can manage information on applications to which they are assigned access then you have read only users which can only review and view the reports [Music] they can just view users groups and apps but cannot modify any settings they can view but not modify organizational settings and then finally you have mobile access mobile admin access was full access to the mobile related permission sets and has limited access on non-mobile permissions so that's like your different uh administrator roles which we have in octa then finally you have this api and api token this is actually one tab only if you'll see that you know we are getting two api only so this is kind of a single tab only over here in api uh over here in api you will have you know authorization server which is important if you are talking about an oidc app and then you know api tokens are required for you know you to automate a lot of things in octa uh like you know you are being adding the users manually or you are integrating applications manually or you are creating mfa policies manually whatever we see on the admin ui right that can all everything can be done enough by using an api and for us to do through an api we require an api to open so you know whenever like you know i can go ahead and create a test token once this is created i can only view it once so i have to copy it and now we got it and this would see that you know this would show me who has created the token by what level of privileges that user has and you know when this would expire and stuff like that if i do not use this token for the next 30 days automatically this token would be expired that's why you'll see a different i mean uh you know it says that expires on june 14. so basically whenever i'll create it after 30 days this would be expired so so that's you know time offered open and it's required because we have to you know whenever we are making use of octagons api tokens are the most important things that order you know the the prerequisite of the very first thing which we require in order to configure an octa api so i'll just remove my token and then you have trusted origins also under trusted origins like if in case you are doing a javascript you're building an application on javascript in that scenario and it's there is a request coming from same domain or some different domain uh you want to add that origin of the domain over here then you can just go ahead and add it so you know you can select pause or redirect if as per your requirement this is all together a different concept and you know an advanced level concept so i'm not discussing a lot in the fundamentals class but uh like you know people who code on javascript they'll understand that you know sometimes origins needs to be trusted uh then only they would be you know able to access octa apis through their javascript code and in order to do that they have to add operations over here in opera so that the request is being granted by opera when it hits the uh when or when the javascript application hits the environment so that's that's pretty much it under what we have at the security tab so we have basically covered all of these topics today we have covered general health insights of the integration mfa idp dedicated authentication network behavior detection administrator and finally the apis of octa we have a lot of things to cover under aps um we haven't seen what are you know the different types of apis or how do we add use through eps or not but that and all is covered under advanced training under fundamental uh section we have seen that you know what are the different types of stuff which we have in octa and we have kind of given an overview of how you know all of these things help and why do we have these tabs and you know uh and what purpose do they solve so that's yeah that's pretty much it from mine so let's go ahead to the octa tenant and you know see whatever we have under uh the admin console so as far as what we have completed till now is that we have seen on the directory tab we have gone through all these you know directory tabs uh then we have also gone through all the uh security whatever and headings we have under security tab we have seen that under applications also we have seen how do we integrate applications we will be creating this you know in octa integration network that's all together a different topic so we'll cover that in our last video and then you know today we are going to see about um these two tabs that is dashboard and the customizations although these are not very you know uh not something uh that should be covered under the fundamentals topic but you know um especially customizations because this is the recent feature which has been introduced by opta so you know we'll just have a quick overview of what these are all about and we'll see you know what are they what actually do they contain so i'll go to the dashboard tab first that's the very first tab that we see in our on our offer and you know over here we'll see whatever we uh you know whatever the dashboard we have for the octa so over here when i click on the dashboard right so as an octa administrator i can you know see the dashboard of my application i can see that you know how many users are there uh in last seven days how many groups we have created how many applications are using single sign-on then you know i can see that what is the octa service are there any agents required or not what is the status of those reasons if i have you know any agent integrated on my octa environment you know we have like what all the things we need to do uh if you guys remember you know you would have i have shown it to you that you know what exactly are the things to be uh which octa recommends under octa threat insights so these are all the tasks which you know uh octa accumulates and show us over here which we need to you know complete as an octa administrator and then you know it helps us to provide some information about which application is able to do provisioning which is not able to do provisioning and stuff like that then you know there are some org changes which would have happened in last few days so that's what it is showing to us and you know if i just view all of them so i could see that it's showing me that who basically it has redirected me to the logs page now but you know over here if i need to see something it just tells me like you know which policy was updated and by whom it was updated on which date and time stamp and all so you know and also we have the rate limit monitoring so basically whenever we use eps of octa so we have a late rate limit monitoring for those apis so you know we can monitor it from the dashboard itself and you know security monitoring is something which we have already seen under here under security and health insight so over here you know whatever task we have completed uh if i go here i have 78 so that is something i will see some similar on my dashboard as well so that's pretty much it about our you know octa dashboard so basically you know a dashboard as the name suggests it basically helps you to provide all the information whatever major changes that are happening on your organization or on your tenant and you know major things which you need to worry about or take care of and you know how are things going or how are things happening we can you know see all complete consolidated report or an overview of all those things on a single piece that is the dashboard of octa now if i you know go ahead to the next thing that is task i see that you know i have around 42 hours to be completed and this is that you know application account needs the provisioning so basically you know that's what my 42 tasks are that uh in which you know i have got a total three application and under these applications i have got you know uh three tasks for test before 20 tasks for open id client and 19 tasks for this test web app or transfer web app so basically i need to you know just go through and uh you know check what are all the tasks i have so you know this particular user is auto deep provisioning is not available for this app so we need to manually reprovision the user this account in the app so basically you know i can mark it as completed and i i can you know select what was the resolution i have done maybe i'll say that it's a personal account and you know it's not required same thing i'll do over here as well because all of them requires the provisioning so i'll say that it's not required and now you'll see that you know one by one slowly slowly all my tasks would be gone now it's happening i guess so i think i have some task which is not allowing me to do it directly over here once now i'm left with 99 so i think it now it's more of like that we need to do it manually one by one but that's how you know you need to go ahead and you know take action on these particular tasks and whatever are the tasks which we have pending under the task section of the dashboard column then if you talk about if we go to the next setting that is the notification so whatever notifications you get on your screen you could you know see it over here also if you want to send a message to someone or you know certain groups or users you could just send it and you know all those end users are going to receive a notification from the uh organization at the organization level and you know this is the very first page which we see on every class that is you know that's getting started with octa so basically whatever our you know our application can support and what are the functionalities of this application we could view all of them under the getting started tab of dashboard so that's pretty much it it's very easy for us to understand the dashboard tab and the next is next what we have on our plate is the customizations tab uh this has been recently introduced by octa now but a lot of times what happens is that you know see if i'm using this this is a trial version of my account but it's using you know it has given me a web address url which i don't like it because you know i don't want to use this thing or i i know that you know no one would be able to remember this url so basically i want to use a custom url domain for which i have already purchased the license for from you know i've already purchased a domain let's say so i want to you know replace this url with that particular thing so i have the option to you know finally go ahead and replace my url and that can only be done if i have a domain being uh purchased right now i don't have any domains being purchased so we cannot have a practical shown for it but that's what this you know customization helps us to do that you make you want to change the domain or the url of your application of your tenant you can go ahead and do it now also you know uh sometimes it requires that you want to do certain branding on your application on your tenant because you know you just want to show it because right now i have a tenant which just shows the branding of octa but let's suppose if i have my own organization and i want to show the branding of my organization then there is a way you know we can all upload the themes and you know decide on the colors and stuff like that so that can be done under the customization tab then uh whatever you see on the sign on page sign in page what that octa page comes up right like this uh if i just have to show you maybe once okay sorry i'm already logged in so it will not work over here but let me show it on the in cognitive window so over here this particular screen that comes up right if you want to change the you know the look and feel of this or you know if i want to change something that can be done by editing the you know this html code has which has been written for this particular field so that can be done as well then if in case you know we want to change the error page whatever errors are being you know you we want the errors to be displayed in some other manners then again we have the code written for it you can change the html content of that code and accordingly the error messages would pop up then if you want to customize the footer of your application so that can be done by uh you know that can be done again so basically you know you can go ahead and either select it's powered by author it's not powered by opera so for me i'm fine having it powered by octa because this is my personal account then what are all the emails being sent by octa tenant at different different you know levels that can be seen from you know emails tab if you whenever a user is activated or an ad user is activated or ldap user is activated this is how you know emails have been triggered so if you you know if you're using a paid version because as it says this is a paid feature if you're using a paid version you can go ahead and customize it since i am having a trial version so it doesn't allow me to customize it but whatever emails have been triggered from octa you can customize all of those emails from optics then we have a sms you know whatever sms are being are being sent from octa to the phones we can you know add a translation or you know we can decide which language it will go i can decide any language and you know emails messages would be triggered in that language so basically that can be done from here and then you know finally you have the other customizations available in which you can see the user account information or the display language currently it's english you know if i change it to some other it would change and you know now everything would be changed if i go in you know maybe i think could be a possible that you know it's not available in the free version so that's fine we'll go back and you know we'll change the language to english otherwise we won't understand what we are trying to learn here okay so and then under sign in page you know uh what are all the things we will be able to see and then you know what are the communication things then sometimes we use the provisioning or just in time provisioning so we can mark or edit these things from here and that's it like you know we have some other configurations which we might be uh using you know so we could just come in and you know make this the changes here and the other customizations and it would accordingly work so that's pretty much it for you know the dashboard and customizations these are you know very basic tabs you might not be using it for most of the times but you know uh i just wanted to give you a quick overview of what they are and what they consider so that's it from mine we'll see in the next video uh with the workflows reports and settings which is you know an important part for opt-out so we have gone through the dashboard directory customizations applications although we haven't you know seen this these two that is the octa integration network or the sales service and then after that we have you know completed the security tab we have understood you know each and every uh sub headings which we have under security and today we will start off with the workflow uh now you know workflows uh aren't supposed to be covered under the fundamental training so i would just be you know giving you uh some idea some brief about you know what workflows we have in octa and how you know these workflows help us to ease our process in octa uh also you know this is not available in the free trial version so even if someone wants to you know go ahead and create certain automations in octa or you know write workflows in octa i mean workflows are not free of cost uh they are you know available in the paid version uh and automations you can do but you know they there aren't any much automations which you can do from this particular page so i think i have been logged out from my id so i'll just quickly login so yeah okay so if i i was talking about workflows over here you know if i go to the automations tabs of workflow so i have you know certain automations which i can create uh but you know these doesn't allow me a large variety of you know automations to be created here in octa it's basically based on the user's life cycle management that i can go ahead and create an automation but there is a workflow console i cannot see it because you know i do not have that license version of workflow but when you have the license version in that you get an option of workflow over here by which you can you know uh write proper workflows which helps you to automate a lot of process and octa so we'll try to understand what are you know automations in octa so under automations and hooks you can create workflows so octa provides features that enables you to automate and customize your octa processors with these automations you can prepare for in response to situations that occur during the life cycles of the end user who are assigned to an octagon event hooks enables you to trigger process flows within your own software systems and with inline hooks you can pause your workflows to make outbound calls to your own custom code so basically event hooks it enables you to trigger your process within your own system whereas uh inline hooks they make outbound calls to your custom code what you have written so automation the response to changes in your end users life cycle events triggers process flows in your own software system and inline hooks integrate your custom code to the outbound calls or the octa workflows so talking about automations octa automations enable you to quickly prepare and respond to situations that occur during the life cycle of end users who are assigned to an octal group this helps improve efficiency and satisfaction amongst partners and contingent workforce for example an automation can help for inactivity local employees suits if a user has been inactive for a set of number of days and is on the verge of being locked out you can use an automation to alert the inactive user in advance so basically whenever an a logged out user is going to be inactive in octa or you know it's on almost on the verge of getting locked out so it would you know automatically send an email alert to the end user saying that you need to log in or you don't need to you know do certain action in order to remain your account active keep your account active so that's like an automation you know is doing it on its own you don't have to worry though you don't have to manually inform the user that go ahead and you know change your password or do certain activities so that you know your account is not logged out but it would be done automatically by octa so this is you know an efficient way of uh notifying the user so that the user can take the necessary steps before the uh locking out of his account so you can set up an automation by defining the following items it could be defined on based on conditions the criteria that triggers octa to perform actions upon a group of end users for each automation you can choose one condition to apply to more one or more groups conditions can be scheduled to run once or to record daily the following conditions are available which are user inactivity in october the password expiration and octa these conditions are triggered according to a schedule and can be applied to one or more groups conditions are mandatory for automations on recurring schedules so you know maybe this is kind of too much of theoretical so i'll just you know go back to my octa screen now and i'll just you know um walk you through to the automation starts which we see here in octa uh under workflow you see automations in line hooks and even sucks we have discussed all of them one by one we are currently you know talking about automation so i you know if i have to create a test automation so maybe test the automation mind magics i'll create one automation name and now i have created an automation it is asking me to add a condition then only it will perform in action and unless it does not have a condition it cannot perform an action so i can you know go ahead and uh you know select a condition only it allows me to conditions to select either a user is going to be inactive in octa or the password expiration so you know i am saying like whenever the user is getting inactive for maybe like 90 days so user hasn't used octa for 90 days i would say that you know just change the user lifecycle state and make it suspended or deactivated maybe and so any user who hasn't uh you know been uh able to log into octa for next uh 90 days or hasn't done any activity in october for 90 days they would be reactive deactivated automatically so we don't have to you know track every user would be doing it with the help of this automation so that's how automation helps us to you know build effective manners or you know build us effective way of help us to build it in an efficient manner so that you know we don't have to worry about it for everything okay so maybe we can save this it applies to everyone and now you know now i can just activate it so now going forward any users who would be active in octa for you know 90 days that odd user would automatically be deactivated and it will run every day at 9 58 am isd so every day at this point of time it will run this automation it will check if any user has been inactive for 90 days it will just deactivate it so that's how you know strong automations are next are inline hooks so they are the outbound calls from octa to your own custom code which are triggered at specific point in octa process lows they allow you to integrate custom functionality into those flows you can implement your own custom code as a web service with internet accessible endpoint it's your responsibility to arrange the hosting of your code on a system external to octa and octa defines the rest api contract for for the request it sends to your custom code as well as for the responses your custom code can send back the outbound call from octa is called hook so you know that call happening from after is called as a hook your code which receives the call is referred to as the external service inline hooks are synchronous use synchronous calls which means that octa processes the triggered hook is paused until a response from the service is received so synchronous and asynchronous means that whenever the request is gone until it is paused until unless the response is received back asynchronous calls are it will keep on sending the you know request it doesn't matter whether it's receiving back the response or not so not talking about the event hooks there are outbound calls from octa that triggers process flows within your own software system they are sent when specific events occur in your organization and they deliver information about the event unlike in like unlike inline hooks event hooks are asynchronous so last one we mentioned was synchronous now they are in synchronous and they do not offer a way to execute the octa process flow after sending the call the octa process continues without waiting for a response from the call service so to set up an event hook you need to implement a web service within an internet accessible endpoint and it's your responsibility to arrange hosting of your code on a system external to octa octa defines the rest api contract for the request and it sends you a custom code as well as for the responses your custom code can send back so the main difference is one is in line so that is you know uh they are the calls from octa to your own custom code whereas our event hooks they are outbound calls from octa that triggers the process close within your own system so there are details to this which are being covered in the advanced training but right now we can understand you know the basic difference between the inline hooks and the even tools so that's it with regards to you know the workflows tab which we have in octa next you know we'll try to understand the reporting part which you have in octa this is again a very important part being asked a lot in interviews and why we need to understand this reporting stuff is because you know uh anything not working in octa anything where we require logs and octa everything would be under the report section of opera so if i you know directly go to the report section of octa you know it helps me to provide certain reports or you know certain things uh you know certain detailed reports i would say which would help us to you know uh analyze of the organization i mean analyze the organization in which octa has been deployed or set up so you know if i want to get the report of octa password help so it will send it to my email id and you know i can just download it from there so maybe i'll just go back to my email id and i could see that you know there would be a report which would have been generated so see this is the latest email i got so you know i can directly download the report from opta and once i've downloaded the report so you know i have the csv file with me in which you know i can go ahead and check okay which user has logged in what is the status what is the deactivation so password health and all could be managed from this particular report we don't have to you know worry about how to generate it we can directly request that from opera and from there we can you know do it same happens for application reports authentication troubleshooting and all so all whatever reports as per your requirement you need you know you can directly come to the report section here in octa and directly download it then next most important things are your system logs so you see there are a lot of actors and events which have been you know uh which have which which have there are any there are total of 185 events which we can see on my screen right so basically there are a lot of events which are created and all these events help us to understand with whom they have been occurred so like you know this event has been occurred with before good that is the actor okay so basically i if i don't know you know how do i uh get the reports of a particular person so maybe i just you know uh i just did something on maybe like application maybe test application and i don't know what to do about that so maybe you know i can just uh you know write that word write that keyword over here in the search and then actually search it just make sure that you know you have the date selected properly because it could there could be a possibility that you haven't selected the right set of dates and then you know you're trying to maybe uh you know find something so maybe you know see i have just increased the date and i've just written demo so there has to be some demo you know uh some targets or somewhere the demo would be there as a keyword over here in one of the targets actor or even and that's why you know uh it shows me like you know um all those locks which are there uh basically these logs are being generated based on the query so i have just clicked on that and you know you could see that there is a query being generated but we as an octa developer there could be a possibility that we might not know what query to write in those scenarios as i mentioned before we just need to write the keywords with which we want to search it and with those keywords we'll be able to you know get all the logs associated with that wherever you know octa will find that keyword in that particular stipulated time frame so next we have the import monitoring this is basically you know for your active directory or the ldap agents which are integrated with octa so any agent which is integrated with octane any set of users which are being you know imported in octa we can monitor from here so that's what you know the import monitoring do if in case there is something failing or something completed we can you know track the progress from the import monitoring tab and then there are certain api rate limits here in octa which you know it helps us to understand what is the event that happened per hour and you know how much uh what octa apis are we using is it you know violating or not so you know all of these things can be verified or you know viewed from here once you know if there is certain violation we can check and you know accordingly take the action so that's pretty much it about the reports action in report section that we have next we have the settings you know it's very basic thing to understand under settings we have account so you know you have the organizational account i can you know change the name of the company or you know i can add certain information about my organization who would be the billing person to to this particular id or would be reaching out whenever the contract would get over you know and all the end user support and you know admin email notifications i mean some general third-party configurations and all general settings of the application could be you know configured from this particular tab then we have features tab in which you know uh octa generally helps us to understand what are their upcoming features on you know what are they currently working on and what are their preview features and you know uh what all they have closed and stuff like that so we can you know try if you if someone is interested to know what are the recent activities or recent features being developed by octa they can you know come in here to the features and check what is that and then finally you have download so if in case you want to download certain things like the agents or you know the iw agents or the active directory agents or ldap agents radius agents you can directly go to the downloads tab of octa and from here you will get all of that in for free of course i mean you wouldn't have to manually you know kind of go to browser in order to search all of them whatever products octa requires all of them could be find over here in the downloads tab of octa so that's pretty much it with regards to the admin console i'll just you know directly go to the octa application and you know i'll try to help you understand why do we require oin and you know what is the need of it so uh we generally integrate you know different types of applications here in octa so one is your you know saml then you have oidc then you have secure web authentication and basically you know uh you can do it two ways either you do a custom integration which we have done this in our you know sessions before or you go ahead and do an oin integration that is from octa integration network now what is this oin right so we need to understand what is this octa integration network so what octa has done is that you know octa has integrated themselves you know octa has created an integration template with around you know 7 373 application which means that you know these are standard connectors in octa so whenever you want to integrate an application in octa with these connectors you can you know directly go ahead if you want to integrate with salesforce you can directly go ahead and add this connector in your you know add this integration and you you would you know just add the details of your um tenant and that would be it you don't have to you know do anything else apart from that this would just you know directly add your integration or complete your integration very fast now the thing is the same thing we could have done it from you know uh adding the application integration like doing a custom integration instead of going to the app catalog this app catalog is basically your octa integration network so why do we require or why do we use octa integration network the most important reason why we do it is like octa has already integrated or created all the apis with this with this application with all these application and so you know if you want to achieve single sign-on or if you want to achieve provisioning or any other request right so we don't have to do or you know we don't have to make any kind of effort it would be done directly from octa whether whereas in you know if you if you are looking to do a provisioning in custom integration it would take time for you to understand you know what is provisioning and then you will have to integrate it but with these set of standard applications if octa supports provisioning you can directly go ahead and you know directly integrate them and directly you know provision it as a so whenever you go ahead with any of the application right you can see that under the use cases you see what all functionalities are what all features this particular standard connector supports so it supports single sign-on and it supports life cycle management of the user and all the functionalities are that it is supported by the workflow connectors templates it can help you with saml swa or skin provisioning so basically all of these are the use cases and the functionality is being provided by this particular connector of salesforce and now if you want to achieve the same set of functionalities using using custom integrations you might have to write a custom code in order to do it but over here since it's part of one network all of this work has been done by opta and we just have to leverage the services being provided by octa and that's how and that's why you know we have such a strong network of octa we have around 7000 applications on octa you could see which are you know integrated by octa and all the standard applications we could which you could think of all the business applications i mean uh mostly you'll see that you know all of those applications are integrated with octa so over here you can see that you know there are certain use cases which is like all integrations then you have automations you have identity proofing water fraud detection so whatever different different applications have been created for what all purposes you could see that you know all those applications are being provided over here and you can directly you know go ahead and make a connection in octa so basically that's it like you know if in case you want to go ahead and check what all oidc application octa supports or what will saml applications after supports or where in you know a octa support scheme provisioning we can directly come in and you know check it from here so it's a very strong network we it actually helps to reduce the work of the octa developers to a greater extent because we don't have to you know go ahead and write custom codes in order to create connections with these apps instead octa has done all of that work they have very strong apis with these you know uh already being inbuilt apis with these applications which directly communicate and you know uh which directly communicate and you know works with these applications so any single sign-on on any provisioning or any scheme request or any api request if in case we don't have a standard if yeah standard connector available in the oi network then only we'll have to you know create an application custom integration otherwise we we can you know directly use the on network application so that's all we have for you know the octa integration network it's a small topic but an interesting one to understand and i think with this we are able to complete our fundamental goals so thank you everyone and have a good one take care [Music]