[0:08]Let's get started with the next lesson of this module, introduction to EIC authentication and authorization. Before getting into Saviance EIC authentication, let's understand the common concept of SAML single sign on. Security assertion markup language 2.0 enables the secure exchange of user authentication data between web applications and SAML providers, such as identity provider and service provider. When the end-user uses SAML 2.0 protocol to enable single sign-on (SSO), security tokens containing assertions pass information about an end-user (principal) between a SAML authority - an identity provider (IdP), and a SAML consumer - a service provider (SP). This is the standard procedure in which SAML single sign-on works. Saviynt Enterprise Identity Cloud (EIC) offers a SAML-based SSO service that provides an enterprise with complete control of authentication and authorization of user accounts that can access the EIC application. In this scenario, EIC acts as the SP and supports SSO through SAML using external IdPs. There are several open source and commercial IdP solutions available that you can use to implement SSO with EIC. EIC is compatible with all external identity providers that support SAML 2.0. After you configure SAML SSO with your organization's IdP, when a user navigates to EIC, they are then directed to the IdP's login page for authentication.
[2:18]After successful authentication, a user is redirected to the EIC home page. Let's understand the single sign-on flow briefly. SAML SSO works by transferring a user's identity from the IdP to the SP through an exchange of digitally signed XML documents. A user tries to access EIC URL through a user agent, for example, your browser. So basically, a user will log in to the browser, enter his EIC URL. As soon as he enters his EIC URL, EIC is configured as SP, and therefore it directs the SAML request to the user agent. And now the SP initiated flow begins. The user agent relays the SAML request to the IdP, and now IdP initiated flow begins here. IdP identifies the user. IdP generates a SAML assertion file as SAML response and sends it to the user agent. It embeds the requested user attributes in the assertion file. Now the actual validation and authentication happens. The user agent relays SAML request to the service provider. And now, as part of authorizations, service provider authorizes the user and displays the EIC home page based on the user's role, if the user is available in EIC repository. If the user is not available in EIC repository, then the request is rejected. This is the standard flow of how single sign-on happens. In the upcoming modules, we will understand this in more detail on how this can be configured based on your identity provider, either Okta, Azure, or any other provider you are using. Once the authentication is successfully done, let's come to the authorization part in EIC. Authorization is done in EIC using SAV roles, which is short for Saviynt roles. SAV Roles define the privileges granted to users which controls what end-users can do at both broad and granular level in EIC application. So basically, if you are an administrator, then you might have the complete view and the capability to access EIC application and take various different actions. Whereas if you are a help desk member, you might have limited scope to use EIC. If you are an end user, again, you might have limited scope, but if you are a manager, you might have broader scope. For example, you should be able to accept user requests, reject the requests, perform certifications, and much more. So the benefits of SAV role are that it lets you drive persona-based access control. So if you are an admin, you will have a greater level of access as compared to an end user. Saviynt lets you define these features like what level of access will be granted to which persona using these SAV roles. This reduces administrative work and IT support as the level of access given to different personas is predefined. This also helps in maximizing operational efficiency and improved compliance. Now let's look into some of the common personas. SAV role is assigned depending on whether the user is an administrator, a specialist, or an end-user providing them with different personas. These are some of the common personas like we spoke about. Saviynt Admin, Helpdesk Team Member, Reporting Manager, Role Owner, other personas can be your compliance officer and so on. Depending on the persona of the user, we can define what level of access they will get in EIC and what functions they can perform in EIC application. To further talk about the usage and benefits of SAV roles, these restrict user access to EIC feature and hence complies with the security. These allow users to access roles and applications that they need right from day one of joining an organization. You can instantly change or revoke access rights when necessary. For example, when an employee moves to a different group or leaves the organization, or his title is changed, his access can be redefined accordingly through the SAV role, and this can be done in automated fashion. So this helps reduce potential errors when assigning user permissions to the users. This was just an introduction about the authentication and authorization mechanisms used in EIC. In the upcoming lessons, we will go over those topics in more detail and how to actually implement them. This brings us to the end of this lesson. Thank you.
