Beyond HR driven identity

[UPBEAT MUSIC] Hello and welcome. My name is Torsten Westphal. I'm a process engineer for One Identity, and I'm joined today by Marc Maguire, a solution architect for One Identity. And we're going to talk about beyond HR driven identity. [PAGE TURN] The agenda going over what actually HR driven identity is and what the limits are, and then especially the limitations when it comes to B2B or B2C use cases. We'll have a brief look at decentralized identity, and then of course, looking at bigger projects, such as the European eIDAS project, which can be used to enrich HR driven identity. Marc will explain the XIAM concept. And then we're going to see how it all falls together. And there will be plenty of very interesting demos and how we can all make use of different technologies in order to overcome these limitations. [PAGE TURN] HR driven identity has been around for a while, and companies see more and more the benefit of having a HR creating the user account through their management system. The user account will be provided, provisioned directly in. HR driven identity has been around for a while. And companies do see the benefit of having the human resource department create the user in their system with all the necessary attributes, correct data, and then have this being fed directly and automatically into an IdP system, such as OneLogin. OneLogin itself supports many HR management solutions and sources of truth, and the exchange of data is usually done in real time. [PAGE TURN] Obviously, sharing employee data between HR MS systems and an enterprise directory like OneLogin is a huge gain in productivity and in security, simply because reduce errors, of course, right, data entered by HR usually is very precise, for obvious reasons. It will speed up the provisioning and deprovisioning process into and from IT systems, so data flow can be automated, and this in return, can then action on what the user is able to access. If there's any change in the user position or attributes, well, this can then get captured as well. And OneLogin, for example, would reprofile the user in its system. Talking about accurate data, so if anything changes, then OneLogin, for example, or other systems, will make sure that this information gets synchronized down to the application that are capable of receiving this type of update. We can reduce risk, because we can limit or disable the access to resources as soon as HR suspends or moves the account into a different role, maybe in a waiting position, and therefore, OneLogin, for example, can strip off all the access rights. It's all but logic, that it saves time and money and it greatly improves user experience through SSO. As an example, how many times have you started a new job and you've been waiting the first day for your environment to get ready? Well, in this HR driven identity, through OneLogin, it would be a matter of minutes for your account to be already set up and provisioned into applications that you will need. We can also run all the processes eliminating dependency of internal team. So, if the data is accurate and we have it in the system, that's good for us. We wouldn't need approval systems. We could introduce them as needed, of course, through third-party solutions. But in general, it is all preconfigured. And then we ease auditing and security insight and much more. So overall, it's a great solution and it has been around, and it's proven its purpose. [PAGE TURN] So what would be the limit of air driven identity? Well, for example, if we have to handle data from partner users or customer identities or maybe sources of truth over which we have absolutely no control of data quality or accuracy, like ID verification-- --or maybe if we want to verify the occasion level or qualification, clearance level, again, financial compliance or any governmental ID. So we depend really on external systems. And that in itself poses a problem if we try to use our HR system and apply the same rules, but for populations we really don't know. [PAGE TURN] So if we think about large numbers of business to business partners, let's say outsourced IT operation, managed service providers, if we bring them into our HR system, well, it could consume a high number of licenses, which it wasn't really made for. Somehow, the HR team would still be in charge of this population and create and curate the B2B worker data, which is not really their responsibility. And that leads to another major problem, is if these identities are not being checked on regularly-- --well, they would just run in the system, turn stale, because HR would not be necessarily capable of rechecking or approving or recertifying if all these external identities are still OK, valid, up to date, and active. Then, of course, the responsibility for data accuracy is not very clear, as this lies with external service providers or external customers, and not with HR. And then the most worrying factor, is that very often, the templates for given birthrights when we create a user in HR system can be mapped to some internal resources they actually shouldn't get access to. So we overprovision the external user to our resources, although the contrary should be the case. They would really just get what they need, and nothing else. So lots of problems that start arising when we drive HR driven identity workflows in conjunction with B2B or SIEM use cases. Clearly, this has not been made for these purposes. So maybe we take a step back and we look at the basics. And that usually starts with an individual and a physical identity, a user who can then have multiple diJITal identities. [PAGE TURN] Thank you, Marc and Torsten, for giving me the opportunity to be here today. My name is Juan Jose Sánchez. I'm Service Manager at Wise security Global. I'm going to delve a little bit deeper into the digital identity model. [PAGE TURN] Here we can see a high level overview of the digital identity model. In the center, we can see the user. It's the owner of the information. And in this kind of model, he is also the only holder of this information. And that's why that kind of models are also known as self-sovereign identity. [COUGH] On the left side, we can see the issuer. It's the trusted source of the information. And they will-- the entity that will create the verifiable credentials for the user. And finally, on the right hand, we can see the relaying party or service provider that is the entity that requests the user information in order to grant some services or access or any other kind of service. In these models, all the information exchanges are done through the subjects. They receive the verifiable credentials from the issuer. And they share these credentials with the service providers. So the relaying parties need some way to verify that the information they receive can be trust, and it's true. [COUGH] And this is where the blockchain comes into play. The issuer will record into the blockchain all the necessary information to verify verifiable all credentials they issue. And usually, the public key used to sign the verifiable credential. And also, the status of every credential. And so the relaying party can read into the blockchain information they need to verify and the credential they receive from the issuer and to verify that it has not been altered and decide if they have to trust the issuer or not. Also, additionally, registering the status of affirmed credential allows the user to revoke this credential and immediately all the relaying parties will know that this credential is no longer valid. Because updating the status in the blockchain, all the relaying parties will know at the same time. This is especially important for companies when an employee leaves, for example, because they don't have to delete the user or disable the user in different tools, different platforms. They only have to revoke the employee credential and he will lose the access to all of the systems. [PAGE TURN] But this kind of model could be implemented without the use of blockchain. So, why did we choose to use blockchain technology? We found four major benefits in the use of blockchain. The first one, and the most obvious, is the decentralization. You have the information all over the network. It doesn't matter if one node goes down, two, three, the whole network will be still working. And all your information will be accessible. The second is the immutability. All the information you write into the blockchain will remain the same forever, and you can make new writing, new annotations of the status update, and you will have a chronology with all the changes that the information along history. The next one is the timestamping. Every block created into the blockchain have a timestamp. And additionally, every block that is created after the first one will renew or validate again the timestamp of the previous blocks, and also the content of these blocks. And the last one is the ability to use the blockchain like trusted public key list, where we have the public keys of all our issuers and in one single place and always accessible. [PAGE TURN] [AUDIO OUT] implement this model to bring this technology to the final users is why we have created-- Wise security Global have created the Wise DID Authenticator. And Marc will show you this application, the basic functionality of this application later, so I'm not going to repeat. But I want to highlight two different functionalities. The first one is the ability to create a verifiable credentials or verifying the claims. The Authenticator can create an email verifiable credential and telephone number, verifying the ownership of the email address and the telephone number through code, OTP codes. And also, can create verifiable credentials of personal information through a KYC process, where the user will need to take a picture of the national identification document, like the passport, national ID card, any kind of document that includes a photograph of the owner-- --and go through a facial biometric process to verify that he is the owner of this document. And the authenticator will create verifiable credentials of the information extracted from this document. And the second functionality that I would like to highlight is the possibility to hold verifiable credentials issued by third-party issuers not related to Wise security or OneLogin if they use the same-- if they use the same standards. [PAGE TURN] Regarding the standards, we have built our application on well-known standards, like the W3C, or the credentials structure and presentation request, OpenID for the protocols to authenticate and authorize the users, and the JWT for the information that travels between the different groups. And that concludes my presentation. Thank you very much for your attention, and I hand it back to Torsten. Thank you very much. [PAGE TURN] What is an electronic identification or digital identity? Well, it is a proof of identity of a person or an organization that we use in our digital world to access services, just for legal purposes or financial health subjects, education, public service, leisure, and so much more. Since we're dematerializing all aspects, well, we should introduce a strong layer of trust. [PAGE TURN] And talking about trust, this is precisely what is being made currently or achieved and discussed by the European Union. They came up in 2014 with the eIDAS program, which stands for Electronic Identification Authentication and Trust Services. It's a regulation representing a common framework to which all member states can subscribe still using their own design and functionalities at the state level. This system is even open to third-party states, how they can subscribe this. It is basically the idea that the EU provides a digital version of the physical ID documents. And in lots of countries, we already see this happening. Germany, we have the ID documents. In France, we have, for example, France Connect or France Identity. And everything is converging to join this common framework. In order to use this framework and subscribe to services that provide the highest level of trust, we introduce what we call Qualified Trust Service Providers. The great thing about this is, not only we have the highest level of trust and certification that the identity that presents this digital ID is who we pretend to be, but we also get now the possibility to just share information we want to share. So basically, if I, like you can see here, if I want to share my doctoral degree, I can do so. But this is optional. So I, as an end user, as an individual, I have more flexibility on what type of data I actually want to share with any organization, e-commerce, or my employee, or a university. [PAGE TURN] So if we use this logic of having the highest degree of verification when it comes to my ID, I'd say government ID or other verifiable credentials that subscribe to this framework, well, then we can see a lot of advantages. And these advantages will then become very obvious when we talk about beyond HR driven identity as HR itself becomes a client of an authoritative identity provider. So the advantages are multiple. For example, as we see, transparent and accurate sharing of user data across different platforms or child IDP systems. Cross integration into other authentication systems. And then, of course, things like single-sign-on for integrated application, thus making it extremely simple to sign up and gain access through HR systems or other connected systems to application or services. [PAGE TURN] So let's take a look at how we can reshape this new HR model. So if we start off on our right-hand side here, we can see we have our two external identity provider sections. We've got our low trusted identity providers here. So, our social IDPs, our Facebooks, Google, Apple, et cetera. Then we have our high trusted entity providers here, like we mentioned previously. So we've got things like our bank ID, government EID providers, verifiable credential vendors, and ID proofing, or the verification solutions, et cetera, in this bucket. So we can have these environments integrated into our XIAM platform with our trusted IDP capability. So we can see here, we can support SAML, OpenID Connect external integrate identity provider integrations with Git provisioning enabled as we need. And then over on this side here, we have our traditional B2C apps, which will be integrated into the XIAM platform as well. And then we have our applicant tracking system here, as well, which is then integrated into our HRIS system. We have our HR workforce portal here, as well, down here, which is integrated to our workforce environment. So, if we take the use case now here of a low trust or B2C user here, we can see a little bit more detail on this persona. So, this user can access our B2C applications as a low trust user. So their trust level can remain at a low trust level and they will be able to access our B2C consumer-facing applications as needed. They can register their account from either a low trust or a high trust identity provider, so that's fine. And then like I said, they can only access B2C applications. They won't be able to access any other onboarding or partner portals or anything like this, just purely a B2C use case. Then we have our workforce and our B2B users. So these are kind of grouped together here. These can-- these will always start off as a low trust user and then they will be brought up to a high trust level through-- via some other process, which we'll talk about later. These users must register from a high trusted entity provider, so they must have been-- their account must have been created from something like a bank ID or a verifiable credential service or a government DID ID proofing vendors, et cetera. They will convert to a high trust level following the successful completion of some recruitment or partner onboarding process with multi-stage approvals. And then they will be automatically provisioned down into the workforce environment here once their account reaches the high trust level. So we can see, we have a provisioning integration here between our XIAM OneLogin environment and our workforce environment, so our provisioning over SCIM. And then we have our trusted IDP connection here with over OpenID Connect to authenticate into the workforce environment. So we can see here, like we said in the applicant scenario, a successful applicant will be synchronized into the HRIS system and enriched then in the HRIS system with various details, such as line manager, position start date, end date, et cetera. And this detail then can be written into the user object in the XIAM platform here by using and calling the API to update the user. And obviously set the trust level of that user then to be high, so that they're provisioned into the workforce environment. And likewise, we can see a deprovisioning activities will happen as well here on this connection when somebody is leaving and that trust level has has been modified or they've been added to a Leaver, a Leaver's role, which we'll see in a demonstration later on. And then down at the end here, we can see we have our workforce resources here, all of our on prem and cloud apps that are using the workforce environment. And we can see here just a little overview of how the authentication experience will work for the new workforce user. So the very first time they sign into the workforce environment, they'll be using their XIAM account. So they'll be using that XIAM trusted IDP connection. And then as they're signing in, they'll be prompted to register an authentication factor, specifically in the workforce environment here. So this can be something like OneLogin Protect or a passkey, webauthn, it can be YubiKey, et cetera. And then all subsequent logins into the workforce environment will be using a passwordless flow using that authentication factors that have been registered now, specifically in the workforce environment. So we'll see that in some demonstrations coming up. [PAGE TURN] So a key to this, as you could probably see in the previous picture, is this concept of the XIAM. So well, what is it? So it's pretty simply, it's our IAM environment for all of our organization's external users. So this can include our users from our B2C, traditional B2C cases, our B2B users from existing partners, as well as B2B users from potentially new partners that are currently undergoing some kind of vetting or approval process to be set up as a new partner. And then obviously, then our potential workforce or applicants will be using this environment, as well as our former employees or former workforce users that may still need to be given access to certain Leavers' applications. So the systems then that will leverage the XIAM platform as their identity provider. We can see they can include things like our B2C traditional applications or consumer facing apps. They have things like our partner onboarding portal, our workforce applicant solution, as well, for workforce onboarding. And then like we said, any applications which we need to make available to our former employees or former workforce users, as the case may be. [PAGE TURN] Just to continue further on this, so it's basically, we can consider that the XIAM platform is the bridge between all of our external trusted identity providers and then the end workforce IAM platform. So this is allowing us to have this control and bridge between those external trusted systems and our end workforce environment. So it contains users of varying trust levels. So we have users with a low trust level, for example, can access our consumer facing B2C services, but only those that have reached the high trust level then will be in scope of being provisioned down into our workforce environment, whether that be an employee or a B2B use case, it will follow that same flow and same pattern. So it controls which accounts then that have come from those high trust level identity providers that actually can be provisioned to workforce, and then which attributes are defined and an attribute mapping rule base to apply the appropriate detail into the workforce environment for our new users. And then it becomes the only authoritative source for our workforce environment, so every single provisioning or deprovisioning action into the workforce and out of the workforce will come from originate from the XIAM platform. [PAGE TURN] In order to show how easy it is to set up a trusted IDP in OneLogin I would suggest-- [PAGE TURN] --we just take a look at a small video. In this case, we're going to create a trusted IDP connection with Google. For this in OneLogin, I would go into new trust, give my trusted IDP a meaningful name, and before I hit Save, I have to decide on the type of protocol I use. In this case, we're going to use OpenID Connect. Save that, hit Save again. And there we are. Now we can go into this configuration and enable the trusted IDP, show the little icon in the login panel. Now, this is completely optional. And we have to fill in some fields, which are basically very standard fields. For example, we're going to point to accounts at google.com as the issuer. We can specify a field or email domain. In this case, I'm just going to use this on any user that has a dot Gmail account. And again, we can narrow it down to only allow a certain email domain. And then further down the OIDC configuration, we're just going to copy again and paste some information we need. So for the authentication endpoint, well, this is all information I can get from the Google configuration page. This, of course, is a post operation. We need to fill in the token endpoint, and then the user information endpoint. If you have done this before, you will have this up and running in no time. In terms of scope, again, very easy. We're looking at OpenID profile and email. Now, the two things that we need from the Google side is the client ID, and then the client secret, which will be generated on the Google side. Just paste that in there, hit Save again, and we're almost done. Last thing that we want to do, we want to make sure that the user gets created while he's authenticating through Google, should he not be in the database. For that, just go back into the configuration page, click JIT or Just In Time provisioning. We enable that. And we will set the trusted IDP for the user once he has been created. So the TIPD value is what we are receiving from the trusted identity provider, in this case, it's tipd.email. And we will map this to the user field email in OneLogin. Same for first name and last name. As you might know, these are the only three fields we really require in OneLogin to create the account. We can make it updatable, so that if anything happens or changes on the trusted IDP site while these changes are being replicated into OneLogin. And that is that. So with that, I would now go out and test this. I'm going to use a user who has a Gmail account. Or you can see also the little Google logo down there. I'm now being taken to Google in order to authenticate. Well, that's a Gmail account, that's all grand. So, I'm going to use Passkey, for example, without using my password, but just my smartphone. I'm taking a picture of this and validating it on my phone with my fingerprint. And since this is successful, I'm then being sent back to OneLogin. Well, it's the first time I logged on, I have to accept terms and conditions, and I'm now being placed into my portal and my session, with just one specific application that let's say, an employee or a partner would like to share with me. As you can see, we have transferred the user information and the account has been created accordingly. It's really as simple as that. [PAGE TURN] Now we're going to look in more detail at our B2B use case of onboarding partner identities with this solution. So we can see on the left-hand side, here we have our trusted external identity provider zone. So we have our low trust identity providers down here and our high trust identity providers here. So in this case, our low trust identity providers are not going to be permitted to be used in this B2B partner onboarding use case. So they're blocked off. Then we have our high trust providers, our bank ID, our government EID, and our verifiable credential solutions, which are integrated into our ORG 199 verified XIAM platform. Then we have an integration then further to our workforce environment here. So we have our trusted IDP connection between the two different OneLogin instances here using trusted IDP. So we can seamlessly sign in here. And then our provisioning connection between the two environments, as well, for provisioning and deprovisioning users when they've reached the high trust level. So then we have our partner onboarding system here, we can see is integrated into the XIAM platform. So we're using this as its IDP. When a user signs in to the partner onboarding portal, they can raise their request to be onboarded into ORG 199 project. And obviously, this will go through whatever governance and controls are needed in this scenario. And at the end of this process, the partner onboarding system will basically make a call to the XIAM platform API to update the relevant user with some additional attributes and raise the trust level then of that user from a low trust to a high trust user once they've been-- come through the partner onboarding process. At this point then, when the user has reached the high trust level, we can see that they will be provisioned and can be provisioned down into the workforce environment. And ultimately then, able to access our corporate resources then, protected by our workforce IAM solution. [PAGE TURN] So now we have a demo where we're going to look at how we can onboard our B2B partner use case from a verifiable credential from a high trust identity provider, in this case, a verifiable credential solution. So our user will have a verifiable credential stored on the mobile wallet on their phone, which they can present and use to create an account in the XIAM platform and raise their partner onboarding request then-- --which will go under review and ultimately be approved. And then the user will be updated from a low trust level to a high trust level and provisioned then into the workforce environment, where they can then log in and access all of the protected resources that they've been given access to. [SWOOSH] OK, so in this case, we're going to look at onboarding a partner from a verifiable credential. So we can see here, I have the Wise DID Authenticator app installed on my phone, and I have a verifiable credential already in place here on my phone. So for John Smith, this is all good. We can see it's in valid status and issue A renewal date is there. And we can search. We don't have that user already in our ORG 199 environment, either in the XIAM environment or our workforce environment here. So, we are-- we're good to go and start this process now here, how this flow looks. So we'll start by going to our fictitious partner onboarding portal. We can see that we have some instructions here. That we need to use an account that's created from a high trust provider, so not a social sign on provider, to access the service. So we can click the Login with ORG 199 verified ID and be redirected then to our ORG 199 verified ID service here. We can see then here, we have the option to sign in or sign up with a Wise DID Authenticator factor. So if we click that option, we'll get redirected now to the Wise service. Now we can scan this QR code with the Wise DID Authenticator app and except that we want to share our credential with One Identity, in this case, and we'll be redirected now back to the XIAM platform. And we can see here now, an account has just been created just in time. And we've got some information presented to the user about the process, what's going to happen, and our account is being created now just in time, and the profile created here on our partner onboarding application. So we could obviously here now fill in our details, complete the request here to create our-- finish creating our partner onboarding request. And if we go to the XIAM portal here, then we can see we've got access to some B2C apps and partners, onboarding app, obviously, but nothing else at the moment. So if we have a look now in the Admin Console, we can see we have a new user from a high trusted entity provider in the B2B context. We've got John Smith. And we can see now on the activity log that John has just been created here from our trusted IDP in connection to the Wise DID service. And we've got some details. John's first name, last name, email, and the high trust identity provider level. So we can see we don't have any other information around his trust level or any other details. So let's assume now that the partner onboarding process will complete successfully and the partner onboarding system will make a call in here to update the user record. And in this case, just set the user's trust level to be high. Obviously, any other custom attributes can be populated at this time as well. And at this point, this will now trigger some automation to run in the platform here. We can see with the high trust level now defined, our user has been given a role now, and they can be provisioned to the workforce environment. So again, we see as a admin approver here, I can see that John Smith has successfully completed the partner onboarding process and I have a final review control here now to whether I want to approve this pending provisioning activity into the workforce environment or not. So I can click the user or I can go in and find the pending activity here on the user level. And we can see here, we have that request. So we can give that an approval, and that will kick off provisioning action now from the XIAM platform into the workforce environment. And we should see now in a matter of seconds, that the user, John Smith, has been provisioned into the workforce. So we can see here a lovely green tick, and that looks all good. If we go to the workforce environment now, we can do a search for John, refresh, and we should see our new user now created from the XIAM platform. So we can see John Smith has been created there, and all good. So now if we go back to the portal for the user, we can see they've got now an extra tile for the workforce environment. So they can click on that and be seamlessly signed into the workforce platform and they can be prompted then to set up their local authentication factor here in the workforce environment. So again, we'll use a passkey and register the passkey with the biometrics on this Mac. And we've then created our local authentication factor in the workforce environment. And we've got some terms and conditions for workforce partner onboarding guide, et cetera. And we are signed in now, and we can access corporate resources here of our fictitious company. So that's just how that looks for the onboarding. Now just to show the subsequent signin experience now. And so we can go straight to the ORG 199 workforce environment now. And at this point, authenticate locally within the environment and not use our XIAM environment credentials or our verifiable credential. So we can just populate the username and then we will be prompted in our user policy here to do a passkey, passwordless authentication here, and we're signed in to the workforce environment now and we can access those resources we are permitted to access. [PAGE TURN] OK, so another demo now. We're going to look at how we can offboard our partner, our B2B partner use case here using the same solution. So in this case, our fictitious contractor is no longer going to be working for the ORG 199 environment-- --so he will be updated on the partner management system to say he's no longer requires the access and his account will be updated in the XIAM platform, where he'll be given a role as a Leaver, which will trigger his account to be deprovisioned from the workforce environment and he will lose access to all of the workforce-related resources that he previously had. And we can see then how the user will still maintain their account in the XIAM platform, which they can use to access B2C applications, some other Leaver type applications that they may be entitled to access, or also can use the partner onboarding system once again to raise a new request in the future if they need to onboard themselves again into a ORG 199. [SWOOSH] OK, so now we're going to look at how we can offboard in the B2B user context. So we're going to use the same user we just created in the previous example. So, John Smith here. So we can see John exists in the XIAM platform, and also in the workforce environment here. Last logged in a moment ago in the portal here. NOW logged in as John. We can see he still has access to three cloud services here and everything is working fine. So let's now take the scenario where John is no longer going to be working for ORG 199 project and the partner onboarding system basically will be updated to say that he's no longer requires access. So the custom attribute can be set on the user objects here to add a role to the user here. So we can see a Leaver's role has been added, high trust Leaver role has been added, which will immediately deprovision the user then from the workforce environment. So we can see now that John's account is being immediately removed from the workforce environment. And if we click back into the app portal, we can see that John's session is terminated and he is kicked out, now no longer has access to the workforce environment for ORG 199. So if we have a look in the XIAM platform for ORG 199, we can see they've lost the workforce tile, but they have now been given a Leaver's portal tile so they can see that if needed some information about offboarding So now, just to show they can-- John can still sign in to the XIAM platform, in this case, be redirected to his-- use his verifiable credential once again, so he can be redirected to the Wise service here. And again, just like before, scan the QR code to present his verifiable credential from his phone to the Wise cloud service and be redirected then back into the ORG 199 XIAM platform, where he can basically carry out another request to onboard in the future perhaps, if he will be working on the ORG 199 project again in the future. So we can see, we've got access to those different applications there. [SWOOSH] OK, so now we're going to look at the workforce perspective of onboarding. So again, we can see our external identity provider zones on the left-hand side here, with our high trust providers and our low trust providers. Once again, in this case, we're not going to allow social media or low trust identity providers to be used in their workforce onboarding use case. We will allow our high trust providers. So again, our verifiable credentials solutions, our bank ID, or our government DID services, which can be integrated then into our ORG 199 verified ID XIAM platform over trusted IDP. We then have the same connections between our XIAM platform and our workforce with trusted IDP and the provisioning capabilities. And then we have our ATS system here. So our applicant tracking system, where our potential new workforce users can raise their application to apply for a role in the company. And then this ultimately, when if successful, will create an object in the HRIS system for a new employee, which then can be used then to write back certain additional HR-related attributes on the user level in the XIAM platform. So at this point, the trust level can also be increased then from low trust to high trust once they've been successfully created in HR and approved in HR. And at this point then, the high trust user can be provisioned down into the workforce environment, where they can access all those corporate resources protected by the workforce IAM solution. [PAGE TURN] OK, so now we're going to look at how we can onboard using a bank ID, in this case, a high trusted entity provider. So we'll look at how a new potential workforce applicant can sign up in the XIAM platform for an account using their bank ID, and then sign in to the application tracking system to raise an application for a particular role they're interested in. And then how when they have successfully completed the application process, their account will be updated in the XIAM platform to be a high trust user object with some additional HR-related attributes attached as well. And then, how this user is provisioned down into the workforce environment, where they can then sign in and access workforce-related corporate resources then. [SWOOSH] OK, so in this recording, we're going to look at how we can approach the new workforce applicant scenario using in this case, we'll be using bank ID as a high trusted entity provider. So we have our account, Jim Smith is going to be our user. So we can see Jim doesn't exist in our XIAM environment, and also doesn't exist there in our workforce environment. So we have our new applicant portal here, and we can see we have some instructions here that we need to log in with our ORG 199 verified ID to create an application for an open position. So we can see we can sign up with bank ID here. So we go and do the bank ID signup flow. So we can use our bank ID credentials here to sign in. So our Social Security number and then our bank ID authentication details here. So we'll have our OTP code, and then our bank ID password. And then we should be prompted then to consent to sharing some of our information with the external system. So we'll confirm we're OK with that. And now get redirected back to the OneLogin XIAM environment here. And we can see now we're signed in to the applicant's application. So if we have a look, we can see some of the details have been passed through from the security token into the application, and the profile's been automatically created. So we can see then in the XIAM platform for this user, they have been created, and details from bank ID have been passed across. So if we have a look in the Admin Console here, we can see we have a new user from a high trust identity provider. So we can see Jim Smith here as logged in a minute ago. And if we have a look at Jim's account here now, we can see we've received some information in from that external identity provider. We can see the Social Security number. And we can see the account was created from our trusted IDP connection to bank ID. So everything is looking good here at this point. So, we can see that the user trust level hasn't been populated yet. So let's assume now that the onboarding process and the HR process concludes successfully and Jim is going to be hired. So the HR system can update some attributes here on the user and apply things like staff ID or line manager, et cetera, et cetera, everything else that HR will be authoritative for. And we can see also that the high trust level has been set for the user. So now as an admin who's responsible for reviewing these new user creations into the workforce environment, we can see we get an email notification to let us know that Jim has successfully completed the HR onboarding process. So we can click the link or go in and find the pending provisioning request on that user. And if we're all happy, we can go and approve that. And that will trigger a provisioning action now from our XIAM environment into our workforce now that Jim has successfully gone through the HR process. So we can see we've been provisioned here. And if we have a look now in our workforce environment, we will have new high trust user has been provisioned in. So we have jimsmith@abc.com has just been created in the workforce environment following that approval. And so now we have our user provisioned into workforce. So if we jump back now to the XIAM portal, we can see if we refresh, now the user now has a new tile for the workforce SSO, so we can see we now have the workforce SSO tile, and the user can basically log in to the workforce environment now as a new employee using this. So if they click the link here, they brought in authenticated into workforce and then prompted to set up an additional authentication factor. So in this case, we're going to set up a passkey and go through using the biometrics on the Mac here. And now they're signed in to the workforce environment and they can access corporate resources. So, now just let's see how this looks now the next time the user logs in. So as we said, the next time they log in, now they will be using a fully local authentication in the workforce environment and no longer using their credentials from the external systems, from bank ID or from the XIAM platform. So simply go to the workforce environment and enter in their username here. So, Jim Smith, and at this point, then they will be able to authenticate in the passwordless flow using their passkey authentication factor or webauthn authentication factor that they configured when they first signed in. So we can see we're brought into a user policy requiring passkeys. And we authenticate our biometrics, and now we're signed in. So this will be the user experience going forward then from day two onwards then after they log in. [SWOOSH] OK, so now we're going to look at offboarding the workforce employee from, in this case, with our bank ID scenario. So they have, as we saw in the previous video, we're onboarded using their bank ID through the XIAM solution. And in this case now, this particular employee has been updated in the HR system to say they have ceased employment, no longer be working for ORG 199. And we can see how the onboarding flow looks in this solution then. [SWOOSH] OK, so now we're going to look at how we can offboard an employee using this solution. So if we have a look at our high trust users in the XIAM platform, we can see we have our Jim Smith user, which has been provisioned to the workforce environment and everything is good there. And if we have a look in the workforce environment, again, we can see Jim's account is there and active and everything is fine for the moment, so just like we left off on the previous recording. And if we have a look at the portal itself then for Jim, he's logged in. You can see he still has access to all the lovely corporate resources here that he needs to do his job. So now let's assume that the Jim's contract is finished and he's going to be updated in the XIAM platform that he's now no longer working as an employee. So this can be done by signing a custom field to the user, which will trigger a mapping to apply a role. And we can see here the high trust lever role has been manually just applied in this case to Jim, and he's been deprovisioned and removed immediately now from the workforce environment, so the account no longer exists. And now if we have a look in the portal, you can see Jim's session is finished and he can no longer access anything here now in the workforce environment. So, this is what we would expect in a offboarding flow. If we have a look, then we can see Jim still exists here in the XIAM platform, but obviously no longer in the workforce. And so this is what we would want. So let's just see now. Jim can obviously can still log in to the XIAM platform, so he can still access other services that are available externally from the ORG 199 company. So he can again sign in using his bank ID, just like before. So Social Security number and OTP code and password with bank ID. So, this is the same as before. And again, just, he should be prompted and just consent to share this information and he'll be signed in now to the XIAM platform and can see-- he can now he can access HR Leaver's portal, which may be needed for pension information, et cetera. He can also access some B2C apps. Or he can also access the applicants application once again if he would like to make a new application in the future to come and work again for ORG 199. [SWOOSH] The key, as we saw in this solution, is really the connectivity between the two different OneLogin environments, our XIAM and our workforce environment, and the real power of this is the provisioning connection between the two environments. So in this demo, we're going to see how do we actually set up this provisioning connection between the two OneLogin environments using SCIM, and this time, using a Starling Connect cloud service to support that integration. So we'll see how easy it is to go ahead and configure this connectivity between the two different OneLogin environments. [SWOOSH] OK, so in this recording, we're going to look at how we can provision users between two different OneLogin instances using Starling Connect. So we can see we have Starling here, and we've signed up for a trial of Starling Connect. So this is all we need to get this working. So we have our target environment here, so our ignore OneLogin and our ignore 22 will be our source environment where we're going to take the users from. So we're going to provision into the ignore.onelogin.com environment. So we first of all, start off by just creating an API credential that we will use for the Starling Connect integration. So we can give it a name. So in this case, Starling Connect is fine. And we can give it a manage users permission. So this is the API credential we will use now for connecting the Starling Connect environment to this particular OneLogin instance. So if we go to our Starling Connect and go log in here, now we can see all of the different connectors. So if we do a search for on OneLogin, and we can go and configure our own OneLogin connector here. So we can use the version 2 and we can go now and get our client ID and client secret for the connection. So that's all we need for the connector is to define the client ID and client secret for our target [INAUDIBLE] environment, and also then just define whether it's the US or EU shard. In this case, I'm using an environment on the US shard. We can leave the rest as default here. So we can do a test connection to make sure everything is connected OK. That's great, all done, and save that now. So this gives us now our SCIM URL that we can use now further on in the next steps. So we can see you have an active connector now to OneLogin. And this is connected to our ignore environment. So now let's do the second side of the connection, where we have our source OneLogin environment where we're going to provision users from. So we can go now and do-- create a new application and search for Starling Connect in the catalog, and we can find the EU shard version and give it a name here. In this case, we'll just call it Provision to ignore. And it will log on and save this application. So now we need to go in and apply some configuration to the connector. So we need our Starling Connect client ID, client secret, and the SCIM URL. So we can go back to our connector that's connected now and copy the SCIM URL and paste that into our Starling Connect SCIM URL parameter. And then we get our client ID and plug that into the client ID section, and then the client secret from Starling Connect as well, and apply that down into the Starling Connect client secret parameter and save that off. And so at this point now, we should be able to create a connection and hit the Authenticate button and to connect now to our SCIM server, and we can see it's connected successfully. So now we can just enable and configure the provisioning as just like any other provisioning connector. So in this case, we'll just have an admin approval for create user and enable the provisioning. So that's done, all fine now. So we have the other side connected. So now, let's just create a role, which we will use to control which users are provisioned into our target environment. So, let's just give it a name, ignore.com, and let's select the connector that we just created. So, that's our provision to ignore connector. And save the role. So now we have a role with the provisioning app associated. So let's find the user now that we want to provision. So we have Jane Smith here and we can click on Jane and simply just apply a role-- the role will be created there, ignore.com. Apply this to Jane's account. And obviously, this will now kick off provisioning activity. And we have a pending approval needed here. So if we go and have a look at the configuration of the connector, then we can see some of the mappings in the SCIM payload. We can see here our SCIM JSON template. We're just mapping some simple fields. The display name to username, first name, last name, and email. So very simple SCIM payload here. So let's go ahead and approve the request for Jane. So if we can go back to Jane and find the pending provisioning action and give it the approval. And we can see now this kicks off a provisioning activity to the target system. And if we refresh here now, hopefully, we'll see we've got a green tick now, we've been provisioned. So if we now have a look at our target environment and our users, we should now have a new user, Jane, who has just been provisioned in from the ignore 22 OneLogin environment. So we can see Jane has been created via API and that's perfect. And we can have a little look in Starling Connect now at the logs for connector logs, and we can see here, a user is being created, 201 response, everything is perfect here. [SWOOSH] [HIGH-ENERGY MUSIC]