Transcript
You know, we all are recording from Austin. So let's do, so we'll say like, when in Austin, let's do how the Austinese do. So howdy all, welcome to the session of Diving Deep, Mastering the Symphony of Identity Security Cloud. I'm your enthusiastic speaker, Harsh Amin, and here we go to our agenda. So the agenda kicks in with ISC 101, when we all are talking about certain general aspects of ISC, which are one of the most important areas to understand how ISC is operating. Then we advance to some minishoas around ISC, where you're focusing on detail aspects which are supposed to be taken care into your identity model, your security aspects, automations, et cetera. And eventually we end the session towards the spoke products, which are going to elevate you to the next level of from moving from IDN to which we call as ISC, ISC 101. So we start talking about access profiles. So they tend to act like a needy, attention-seeking child, always furious, don't like something, not going their way. They are short-tempered, maybe most importantly, they're tied to single individuality. So this is the point one where I say, when I call access profiles a needy child, access profile is, let's say, take an example, having 10 entitlements, but due to the overlapping, one of them went away. This child now gets furious and ensures that it throws away everything. So that entire access profile is getting deprovisioned. And whatever all the entitlements, which were alongside those access profile, are just gone. So which in certain situations, it can create a domino effect when you, which SailPoint itself ask you to avoid on subsetting of access profiles. So if you have overlapping access profiles, or we can say a subsetting of access profiles, this can bring you to a state where it brings in a domino effect. So if you start removing one, everyone starts going away. So this is the reason SailPoint suggests you don't do that. Now it's a child, always curious, hence the logic of access profiles, that means the logic that access profiles will be detected if you have any or all the entitlements of that access profile, right? You have all the access profiles, so entitlements of that access profile, you have it. Eventually, now those things are boxed, recognized into a single entity, encapsulated, and existing as a single entity. Let's consider for a child, a jar of candies. So and let's not forget, access profiles are like child. Hence the logic that access profiles will detect, sorry, it will change if you like, by adding more things to its portfolio. Now what it cares about is a new portfolio. Now what it will do is so the identities which matches the old portfolio will now be removed from this encapsulation, and they will be now individualized instead of those entitlements being encapsulated under access profiles. Now there will be a standalone entitlements with that individual, and now this needy child, what it's concerned about is its new portfolio. That is the new sets of entitlements which has nothing to do with what was the old configuration. This entire thing is only with respect to when we start talking about access profiles as in existence and not just an encapsulation of access profiles under roles. Now when we move towards roles, I'll term them as greedy grown-up man, maybe mature, but they always want more. They cannot bear something which is taken away from them. They'll attempt to regain those things. So with this example, we can say greedy because if you take away one access profile or entitlement from a role, then what access roles have a tendency to complete themselves. So when we again talk about overlapping roles, if one of the roles is taken away, which has an overlap, and one of the entitlements or one of the access profiles or multiple of them are taken away, but still that other role does exist with that identity. What roles will try to do is they will try to ensure that the role is complete. So again, greed, they can't stay incomplete, they'll complete themselves. So the roles are the explorers. They have the liberty to have anything from anyone. So again, not bound by sources, which means that new introduction to the roles, even with entitlements, still now we had access profiles just being part of roles now even with entitlements and again, irrespective of sources. Hence now again, when we say it's grown up, so even though they learn new things, they have new orders, they have new mindsets, but they know that things in the past are immutable. So all the access is granted by those roles, no matter you remove the entitlements or access profiles directly, or even just one entitlement from that access profile is getting removed. So it doesn't matter to whatever identities already have those access roles. So it will always come into play for the new roles being provisioned, the old ones won't be taken away, whereas in the case of access profiles, we've seen that they will be individualized. And conclusively, as roles are, once we can say the garments were just short, it's there. So roles, once there, it's there. So now when we move towards sticky accesses, these are the accesses that stay with your identity when you make changes to access profiles or role definitions, and maybe even disable it or even delete them. So just that encapsulation is removed, and the ISC ensures that it's granularized now. These accesses often show up in certifications and have seen to raise eyebrows of a lot of our customers, seeing them outside of the encapsulation or why they're still there. They expect those access profiles to be, they expect them to be encapsulated in their access profile or a role, depending upon their current status, because if they're modified, they're expected to be under that, but that is not how it was initially provisioned. So ISC respects how your initial provisioning was happening and not how you are modifying the things which are into the encapsulations and all, when we talk about in the respect of certification. So it's because certification is snapshot of the time, so even you modified things and all this stuff, but it has a provision, so it took the snapshot and it's available with you guys for assigning those accesses to those identities. And this has been always the concerns of our customers while auditing or during the certification phases that why for one or the other reasons, certain accesses are either not deprovisioned or lying around outside of their encapsulations. Now we moved out to identity attributes, so basics about identity attributes, make it searchable. We are, till now we had CC endpoint to make them searchable, we have a replacement endpoint available out for beta to replace it and we have a hard, hard limit stays same as of now six, and that's the only way you can make them searchable and ensure that those identity attributes are available for you into your correlation logics. Now when we start talking about default identity attributes, which have a back-end mapping to your identity object configs, and these attributes are default, which as soon as you create your identity profiles, they come down with your identity profile. So they are bundled up into the object config. So now when you try to, at this moment, if you check the UI, there are certain identity attributes available with cross marks on a default basis. You have not created any custom identity attribute yet. So by default, there are certain identity attributes which do have a cross mark available for you guys to delete it. There are certain things into this point, well, I'll first talk about the phase like which is available at this point of time, which with one strong recommendation, which you should not opt for from sales, which you should not do with those aspects against recommended by sale point. And I'm aligning with that. And now then we'll talk about what are the changes upcoming. So it would be like if you want to delete those attributes, if you delete it from one identity profile, they will not be deleted from all the identity profiles or they won't be deleted from that identity profile even as soon as you delete it after two, two and a half hours when the identity object, identity object config gets rechecked that that attribute is missing, it will bring that up again. So if you want to delete it in this present time, you will have to delete it across your all identity profiles. Only then those default identity attributes will be not coming up on your future creation of your identity profiles and your existing ones too. So you need to delete it from all your identity profiles. Again, this is never recommended from sale point and we are bringing up our batch to this that now at this moment we when you start creating identity profile, let me take you to the present screen. So when we start talking about here, you'll see all of the initial identity attributes are not deleteable. There are certain a lot, city, cost center, country, department. These are certain of the standard attributes which are coming up. And then as you start talking down the bottom, there is a title, time zone, street address. These are certain 15 out of the box. So there are in total five standards and 15 out of the box which are currently able to be deleted. But soon the decision has been made that these are being made static. That is, this will stay as default. You won't be able to be removing this identity attributes now. So please ensure that even if you are attempting to delete where all the identity profiles eventually someday if you wish to add these things back into your domain, then that would be currently not possible from UI that needs that at sale point has its own back end way that is that might be cost intensive, not sure that needs to be assessed when you come to that point. But at this moment, if you see if you start talking about these attributes, these 15 attributes plus five standard attributes, all of these cross marks are going away. So all these attributes which you see available on your standard identity profile will stay now forever. Now let's switch back to our presentation. So this is all about our identity attributes. Now let's move out to the attribute changes with rule success history. So we have encountered certain scenarios where if you have a rule changes, rule getting triggered on LCS changes or any other attributes, but due to some of your internal policy violations at your organizational level, even after committing a transaction on identity now, you choose out to roll back that transaction because you encountered that this is a policy violation at your organizational level, not at the IDN level. So you choose to roll back that transaction. If you roll back the transact committed transaction, what will please ensure that you are giving a sleep to your threats. You are not doing it any closer to five, six, seven seconds, because what happens is the issue is that the rule changes are if to those attribute values are made too quickly, or maybe to and fro or faster enough. What will happen is less than around five seconds or so, six seconds. So we recommend it. You make a sleep counter of 10 to 12 seconds to ensure that this identity changes are detected by access history because it is controlled by identity refresh, which is running out for access history separately at the back end. And if you don't allow this events to be captured, what will happen is you will see a lot of mess ups around in your search access history, both ways, events will be shuffled up, events might not be there, and you'll be like, in auditing and all this stuff, you'll be like, we did perform certain things, we did roll back. I don't see those operations lying around us. So when you are controlling this via rules, we would say that please ensure that there is a sudden sleep on your threats when you start rolling back your transactions. Now when we talk about certifications, again, well known to all of you from one of the, this is well known 101 in certifications, that any certifications has three end stages. It's either error completed or due date passed. But still we have seen certain areas where customers are getting confused about how to complete a certification. But in that situation, what would have happened is they would have missed out that this certification was never active. They just made it to preview ready and that due date was passed. So those when they end up in due date ready, they can never make it to your completed status. So if you want to wrap it out, that is the opt for a complete termination process for that. So now in error state is like active, if it's active and now you can, as soon as standard certification processes get completed, it goes to completion state. But as I said, from your due date passed, you cannot take it to that. And now the error state is that about where there was, if there was an issuing generation of that certification, then it will straight away go to the error state. And there is another way your certifications can end up with completed status. And that is like when you face the, that there was no identities to be certified. Now we move on to the issue around ISEs. So these are certain fine details we work around in identity now. And we see that usually there are certain configuration misses up by our architects or the identity model designers that they encounter such issues. So when we have a configuration for manager correlation or correlation logic for accounts, everything is right yet the correlation logic is not happening. So first thing you should always check out is that do you have any rules which are controlling your correlations. So your rules can also play a part in controlling your correlations. And rules are greater than your correlation logic, irrespective of your correlation logic. If you have rules defined which are controlling your correlation logics, then we'll be skipping your correlation logics all the way. If rule fails to correlate anything, it won't take you to the correlation logic. It will skip all the way. And then there is no correlation happening. And the rules entirely fails, those accounts stay uncorrelated. Now you define no correlation logic, still accounts are getting correlated. No, that's not a magic. That is just like correlation logic, which is not pronounced out loud, not directly seen on UI. It is the names. If your account names matches to an identity, it will correlate. You cannot call it a hidden correlation logic because SailPoint has made a public documentation to that. But yeah, still it is not too much loud, not everyone is aware. So yeah, that is one of the areas where we encounter these things. And you have accounts coming in from, we can say, same individual for two different authoritative sources, irrespective of sequence of aggregation of those accounts. The one with maximum priority, that is the ISC's least, lower in the number, will have the date, the identity will have its data eventually. It is like no matter what the sequence they came in, as soon as that account from the authoritative source, which has a maximum priority ISC lower number, which will be straight away coming up, the data from that will be populated. And again, your identity is not being demolished and newly created. Identity stays same, your identity ID stays same, just that the data gets moved out and your identity profile gets moved away. So yeah, and now with the sequence of prioritization of your correlation components, it's like you have your, again, you have your UID, if your UID matches to your existing identity, it won't create a new identity, it will straight away link to an existing identity. And then goes out your correlation logic. If there is none found between them, sorry, if none found between these two, only then it will go to this less sound or less vocal correlation logic that is your name. Now when we talk about one of the aspects which you guys should take into account, which is one of the security aspects, I would say when you try to create identities for new onboarding or someone who is like rejoining or something like that, please ensure that you are not giving them privileged accesses or elevated accesses from day one. And also you are disabling their identity now accounts until and unless they are being onboarded because there is a way, because usually we have a standard, corporates have a standard operational procedures that you try to keep your user IDs as either it's email or user first name, not last name or something like that. So in those scenarios, what happens is if some guy has maybe if by mistake or intentionally if they want to hamper the system, they can get into the system even without the invite into identity. So they'll have to just do forget password, follow the procedure there, and they will be allowed to enter into identity now, even without any invites. So you can see on the slides there, that are like, we can see that the person entered and you can see all the operations having of setting up of the questions and all this stuff. But the user was never invited. So if it was some sort of admin elevated access, they can by mistake or intentionally do something which was not supposed to be done and can be a risk to your auditing as well when you put things up for the certification auditing. Now when we start talking about workflows, the majority of our tenants have their workflows around LCS, especially the lever management. So one major miss we have seen here is you configure your workflow such that as soon as your LCS gets triggered, that is your identity attribute change trigger is there. And you have a workflow starting working up, deprovisioning things out or maybe calling out rules and certain performing operations or something like that. So what happens is if you have criteria based rules, which were maybe used for joiners, as soon as you start moving down LCS statuses, what will happen is IDN itself starts deprovisioning certain things. So now in this situation, if you choose to take up a get access call, and then if you take a snapshot, because get access call will give you all the accesses which are available with that identity. And now if you pass that over to the manage access, that we start deprovisioning this accesses. What will happen is in parallel, if in the time your get access call was made, identity now didn't remove it. But by the time your manage access call is getting through, identity now is already deprovisioning that access. So what will happen is your workflows tends to fail. So what we try to recommend is that depending upon the size of your organization, we recommend that you put a wait timer before making a get identity call, immediately after your get access call or get identity call, immediately after your LCS triggers, so that those waits ensure that there is not things lying around, which have been deprovisioned and you are still taking those things into account. And again, the recommendation would be 20 minutes at minimum, and the maximum which would be needed is 61 minutes. You don't need to go beyond that. That wait is good to go. And now we start talking about our spoke products. We jump with NURM. You know that it is some of the crucial parts of any organization, because there are non-employees. And Sailborne gives you supplement to your ISC control with NURM. You can control what all accesses NURM have in a similar way to your employees. So when we talk about your generating workflows with NURM, we have the ability to create a workflow via workflows APIs now, which is now available onto your NURMs. So like we have derived a postman collection setup, which you can fire up for new tenants to create for some standard workflows, where still being dynamically, you are able to set up all the attributes and all the stuff. So let me take you to that screen now. So let's first go to your postman, sorry, this is good to postman, oops, here it is, my bad. So if you're not able to see, I can zoom it out. So we'll be sharing this available, this should be, this postman collection should be available to you guys soon. So let's say we are making automated workflow for all your new tenants and all the stuff. So these are certain variables which are supposed to be fed up by you guys dynamically. You can modify it and hit out these options of workflows with end date, your day of your termination and your profile IDs, which are needed in your NURM tenant. And then when we talk about another one, which, sorry, another one which we have, it's again, the workflow IDs, the email attribute and all, when we talk about those, what are they? So the days are the number of days before and end date is arriving for the notification. So profile type ID is the profile type for running those automated workflows onto most of your cases. And this would be non-employees or the assignment profiles. Then when we talk about workflow IDs, once the workflow is created, it will store all your workflow IDs, email attributes, it is the email attributes for those non-employees. And again, the notification IDs for your notification templates. Now when we start talking about, so now we can again generate a new terminate automation for your new tenant and this can be helpful to create some kind of standard libraries for workflow configurations that can be generated anywhere. These APIs endpoints are fairly new and you can use a simpler example and out to be available right now. And we do have liquid templating available for formatting a lot of things onto your UI, which is available. So something stands out you can do with your templating is your manipulation. We can do it, here it is, for example, the one of the snapshots at the bottom right corner you can see for your profile pages is like what we have done is like we are given the tables name, whatever the attributes we want to populate, again, distributed across four columns and the table.name and your end rows. So it has bifurcated all your available attribute sets which you selected and moderately possible. So we have, if you want to make update to an organizational profile and notify the sponsors about all the affected people that are linked to that organization, the issue is some sponsors have multiple people under said organization. So they might receive multiple emails about same things while we would like to avoid it. So for this, we have a API solution available where we can create a unique list of sponsors with active people linked to specific organizational profiles and set the results out there. So let's go to, can do the postman, now let's see about your, sorry, okay, so this is about your, let's see, we pick up the workflow sessions, okay, yeah, here it is. So we pick up the workflow sessions, we put out those attributes out here with all the profilings, if it's active, conditionalities, and append them to profile owners if we need it. We split the profiles, depending upon that, we loop it and decide to whom do we send, we have to send the notifications and all the stuff, and we can eventually store it to this, and when we start it, when we hit this NOM endpoint, we'll be able to send out those invites to customize invites available. So that was the notification, and now on the other side of NOM, you can use Liquid, which we have just seen, on the workflow pages to display all those tables, it's plated across four rows and all. And now we'll be moving down to the last segment, which would be your DASH, so there are a lot of things coming around for your DASH, which would include your access profile integrations, which you can incorporate with your access history, access intelligence center, AIC, and we have workflow integrations, so trigger responses and remediation actions would be available to file classifications and activity alerts through SailPoint's workflow itself. Now increasingly, the DASH would be into the phase two, the integrations with access history, and the workflow integrations were the part of phase one, which are coming out soon, and with phase two, we are planning to increase it with all the access requests and lifecycle management automations as well. That would be the wrap of your session on everything about IdentityNow, sorry, ISC these days and how you can collaborate and play around with all the different modules, which things you miss out, which things you should be taking care of. Thank you. Thanks a lot. Bye.
