Hello everyone and welcome to another episode of the Identity Renovigator. Today we will talk about Roll-Based Access Control or R-Back. Now if I was to be distilled in just one concept it would be R-Back. That is because everybody knows about R-Back but very few understands it. Also in majority of the cases R-Back programs are messy, sometimes fail and may not achieve 100% success without significant executive mind and long-term commitment. Throughout my career, unfortunately I have got the chance to implement multiple Roll-Based Access Control programs. I did learn this craft from my friend Ulaas Tharakan. So Ulaas shout out to you. He was my colleague at a previous company and is currently a managing director at Deloitte doing extremely well for himself. So if you are in the market for implementing R-Back program, Ulaas is your guy. And just to let you know, I was not paid to say this. So before we deep dive into Roll-Based Access Control, just some personal updates last week was quiet. As some of you know, I am travelling to meet extended family tomorrow, so did some shopping, so read another book or one of the books that I really like which is 13 things that mentally strong people do. So look at my clip notes for that. And you know went out of my comfort zone actually and met a LinkedIn contact on Thursday in a coffee shop. So I met Samir via LinkedIn a few days back and he was in town, so he asked me if you want to meet for coffee and I said, "Yeah, absolutely, why not?" Which is very unlike me, but I finally did that and did go and meet him, so that was good. So yes, another thing, my airports went bust. They now have a crackling sound and also there is no more noise cancellation. Did go to Apple Genius Bar and they said that since this is out of warranty, they cannot do anything for it. So I guess I will have to buy another one. So Black Friday list has already been started. But enough of that, let's deep dive into role-based access control. So if you are here, I already know that you can define I am, but let's redefine I am for a second. So it is a framework. It is to ensure that the right individuals have the right access to the right resources. And that is where R-back is such a core concept, right access to the right resources. So instead of assigning permission directly to users, R-back assigns them to roles, which users then inherit. So think of permissions or you can call them entitlements, whatever they are. So they are an entity that gives you access to carry out a particular operation. And then roles are a collection of these individual permissions or entitlements. And then these roles are assigned to individuals. So if you are thinking about R-back, think about roles as these are groupings of permissions that defines what action can be performed on which resources. For example, an admin role can might have full access. While they read, they might only have view access. And it will really depend upon what are the permissions that are bundled within that role. There are two security principles that you should always keep in mind while thinking about R-back, which is like leased privilege. So give only the access that is needed and separation of duties. And the appropriate responsibility is no single individual has too much power. Now what are the benefits of role-based access control? Simplicity and scalability. Obviously, instead of managing individual user permissions, you are managing roles. So the amount of active objects that you are managing decreases. So the total number of objects increases obviously because now you have permissions plus you have another abstract thing called as roles. But now you are managing roles more than you are managing individual permissions. So that is why it is simple and also scalable. Audibility or auditability, apology. So it is easier to audit user access and ensure compliance. Even during the certification process, nobody wants to certify 3000 individual entitlements. But if you are using role-based access control and the model is good, probably we will have less things to certify or the managers would have less things to certify. And then finally, flexibility. So as needs changes, you can easily modify roles without affecting every user. So let's say 6000 users in your organization have got role A. And now everybody needs to be assigned another entitlement X. So instead of going and provisioning that entitlement X to every user, you can just add that to role A. And that is the flexibility that you get. And also it is the same for how you remove access for all the users at the same time. So I hope that gives you some sense of why role-based access control is there. Now on the same breadth, we have always used policy-based access control and attribute-based access control. Or something new that I am working on which is relationship-based access control. So hopefully we will get a chance very soon to talk about that. But role-based access control is very coarse-grained in nature. And attribute or policy-based become very fine-grained in nature. And we will talk about them in some of the future podcasts, hopefully. But today the focus is on these running a very successful R-back program. What are the gotchas, what you should think about, what are the tools out there in the market. And essentially this is providing coarse-grained access to the users. So how do you plan for an R-back project? There are few phases, right? So let's get through each of those phases one by one. So the pre-layer money reface or let's call it the assessment phase. In which you talk to the stakeholders, identify the stakeholders, carry out interviews, talk to those department heads or IT managers or end users to understand existing access mechanism, challenges and needs. You also document existing systems. You map out current access controls, systems, application that will fall under R-back. Do you want to do it for all the systems in your organization? Do you only want to carry it out for your active directory or Azure active directory? Do you only want to carry it out for high target assets or whatever you want to do? You have to define the scope and then document those systems which are in a scope. And then you identify goals. And I'll talk to you more about the individual KPIs that should be defined. But you have to clearly articulate what you aim to achieve with R-back. Whether it could be enhanced security, it could be compliance, it could be process simplification, it could be all of them. But you clearly have to articulate what it is. So once this assessment phase is carried out and the project hopefully gets kicked off, then you get into the role and role model design phase. So in this phase what you are defining is what are the type of roles that you want to have in your organization? What is the role model? What is the relationship between those roles? And some of the other things like would you allow nested roles? Would you allow one entitlement in a role or verb permission in a role or as role can only be defined if it has more than one permission in it? So these are the things that you define in role and role model design phase. Again, it could very well depend on the company that you are working for and also some of these definitions are used interchangeably. So some might define business roles one way or they might define it another way. But at a basic level these are the different role types that I have seen. So one of them is business roles. So these roles are basically defined based on job functions, responsibilities, your job profile or your business processes. So they represent real word positions. So think of business roles as the tasks within the organization. So marketing manager HR specialist sales executive. So these are the roles which you would resonate most with the business. They help in translating business requirements into excess control mechanisms.
Then we come to IT roles, which are role specific to IT functions. They are obviously centered around systems, applications, infrastructure management, say for example, database administrator or network engineer or application developer. So these are useful to organizations to manage access to IT specific resources and to segregate duties within the IT department. Another thing or another type of roles is birthright roles. So as the name suggests, these roles are automatically assigned to users based on certain attributes or conditions, often at the time of joining the organizations. So what does that mean? So these roles are typically defined based upon the user type. So if user type is equal to employee, they might want access to active directory, they might want access to exchange and things like this. So those permissions are bundled within an employee role and then provision to them. Or it could be based upon user type is equal to contractors. So you might not want to provision visual licenses to your contractors, but to your employees and that is why you will not provision with the permission to your contractors. Now in some companies, I have seen birthright and business roles changed or defined interchangeably in terms of, you know, they also say or you might also come across the line of thinking that based upon your job profile, any role that is defined that helps you carry out your job are birthright roles. So as we discussed in terms of business roles, you know, marketing manager or HR especially is which are dependent on your job profile, they could also be considered as birthright roles itself. So again, it really, there is no right or wrong answer here. It really depends upon what do you want or how do you want to define it for your organization. Another type of roles are application or system roles. So these roles are specific to individual applications or system. They are usually predefined by software vendors, especially since we are in the SaaS ecosystem so much. For example, in a CRM system, roles like CRM user or CRM admin or CRM analyst could exist. This enables fine grade access control within specific applications but they are very, very specific application or system focused. You might also come across a role type called as derived roles. I'm not seen it. Use that many places but some of the places who had good processes defined definitely it. So these derived roles are derived from existing roles by adding or subtracting specific permissions. So they inherit the base permission of another role and might have additional permission of constraints. So to really simplify it, let's say you have a junior developer role that could have been derived from a developer role but with fewer permissions. So these are useful for creating roles that are slightly varied version of existing roles without starting from scratch. So they give you a good baseline. You can have some sort of relationship between them. So derived roles could have a feel that could tell them as to this is the role that they are derived from or this might be completely separate roles, whatever you want to do. And that relationship as to would you be able to tell how your derived roles are associated with your original roles that all comes into the role model. Another role type would be emergency or break glass roles. So these roles are temporary. They grant elevated access and often bypassing standard controls. So they are used in emergencies, right? Like emergency database access. They should be used as tally typically requires approval. So tools like cyber arc or hashie corp where we are dealing with privileged accounts of privileged credentials. These do well approvals comes into picture. And after use, there should be an audit to review actions taken under this role. So ideally we have an audit trail for every action that is taken in the organization or on a system. But these roles specifically, we should be able to identify what were the actions carried out by these break glass roles and always have an approval associated with this. Ideally, what I would suggest is you should also have a service not ticket, right? So if you are using a ticketing system, I've just took an example of service now. So before you get access to a break glass account, you need to have a service not ticket created. That service not ticket would go through an approval process. It might go to your manager or department head or application owner and then based upon that ticket, you should be granted that birthright access for a specific period of time. And when I talk about time, then there are rules like time bound rules as well. So any of these rules could be time bound rules, where I would strongly suggest a guns using time bound rules for business, birthright or IT. But these roles are granted for a limited period. And after the duration expires, access is automatically reworked. So a contractor might receive a temporary project manager role for a duration of a project. So they're useful for temporary staff projects or situation where access is needed only for a short period. On the same lines, you have to define, in your business roles, can it contain direct entitlements? Should it contain a group of IT roles or what it should contain? So all of those decisions when you are taking them have pros and cons to that. There is no right or wrong answer. It should really depend upon what you are aiming for and what is the access structure that you want to create at your organization. But that would constitute your role model. Now the only thing that I would want you against here is I don't like nested rules. And I know that many tools out of the box provides nested rules. But as you go deeper into implementing a role based access control, nested roles are so hard to keep track of and really hard to troubleshoot sometimes. So unless you can absolutely justify that you need access roles or nested roles, I would suggest you to not use it. A flat hierarchy is always better. So, so far we have covered two phases in our role based access control program, which is assessment phase and then role and role model design phase. That brings us to implementation phase, where we are actually going to create the roles. So for this, you might need a test environment because these role discovery or role mining or role creation process is a very, very resource intensive process. You might want to have a test environment or an environment, which has got production data. But at the same time, do not bring down your production systems. You also need to have a migration strategy like how would you migrate the rules that you have mined or created or discovered from this test system or role mining system to the actual production systems. And then training, which is the most important aspect of educating your end users and administrators around this new system, this new process and ensure that everybody understands their role and associated permissions. It would, we will talk about things like role lifecycle management here. How do you create a role? How do you modify a role? How do you delete a role? How do you certify a role? And also what does a role ownership means? Or role owners or administrators needs to be made aware of these things depending on how they are going to be interacting with their role universe. So I've mentioned role mining a few times here. So this is the backbone of implementation phase in which role mining is the process of discovering role based upon existing user permissions. So basically role mining is a process in which we are creating those new roles. And there are multiple approaches. Three of them that I have used or seen most often is the top down mining approach in which you start by defining high level roles based upon job functions or departments. And then you refine these roles by analyzing actual access patterns and needs. So for a company which is very controlled and organized, a top down mining approach makes a lot of sense. So think about this. Are the job responsibilities within your organization clearly defined? If yes, then top down mining approach is the way to go. And if no, do not even attempt it. The second one is bottom up mining approach. So you must have guessed, these are like analyzing existing permissions and groups then to form roles. So you are looking at every user and then what are the roles they have and you've identified
some soft of patterns and then you start defining those patterns into rules. So these are suitable for organizations without clear job definitions or with complex access patterns. Now I have not seen any organization that could just use a top down or a bottom up approach to be honest because some departments like finance or fraud or marketing might have very clear rules defined but some departments like IT might be very different. So for an IT department a developer might mean different thing for an infrastructure team or a cloud team or an IM team or a cyber defense team. So use a mix of these top down or bottom up approach which is called an hybrid approach. So combine both top down and bottom up methods and this is often the most effective especially for large organizations. So how do you actually carry out rule mining? First of all you collect the data. So gather comprehensive data on current user permissions, job titles, responsibilities, HR databases in some cases may be access logs or system configurations. Then you carry out the data analysis. In top down approach you group users based upon their job functions, identify common access patterns and then define rules. And in the bottom up approach you use clustering algorithms like k-means or it could be manual Excel based analysis or you could carry out pattern recognition techniques to group users with similar permissions. I would suggest to use a hybrid approach here so that would give you better roles. And then role refinement. So once you have your basic set of roles created or the crude roles created you use tools like this is entries to minimize overlaps or conflicts. So aim for roles that are easily understandable and map cleanly to business function. Do not try to solve all access via roles. There would always be some outliers. There would always be some roles that needs to be requested. So do not try to define roles for every possible permission or situation. And then validation. Once roles are defined you have to validate them with stakeholders and show their aligned with real word job responsibilities and organizational structure. So in summary implementing our back is a meticulous process and it demands a clear understanding of organizational needs. That is why in this case a business analyst is more important than a developer here. And that business analyst should be a senior BA because they need to understand the organizational needs. They need to be able to collaborate with stakeholders. They need to be able to continually refine the roles. Ideally I would suggest somebody who has been in the organization for quite some time is a great person to be leading this effort as a senior BA. Now road mining by its definition itself is a prime candidate in which we can use machine learning and AI. But machine learning could be used here. Absolutely. I mean I have used k-means algorithm multiple times to define those clusters. Even for data collection using access logs or user attributes. You could be using or could be doing feature engineering which is converting raw data into features that algorithms can process. This could include encoding categorical data or formalizing numerical data or creating composite features. It could be based upon access frequencies or timestamp patterns and user interactions and all can be formulated in the features which could actually be fed into algorithms that could be processed. Clustering. The use unsupervised learning algorithm, k-means or hierarchical clustering are a couple of examples that I have used with pretty successful results in the past and these actually group users with similar access patterns. And each cluster might suggest a potential role. For instance if a cluster of user frequently accesses the same set of resources that might be mapped to a specific rule. Now it is very hard to use this or carry out this analysis using a pen and a paper or an excel file. And I strongly suggest using a clustering algorithms for messy or large organizations. AI or ML can also help with association rule learning. So algorithms like a priori or a clustering can identify frequent item sets or in this case set of permissions that often appear together. And these common sets can suggest foundational permissions for rules. So associated rule learning is a good use case here. You can also have validation and refinements. You can split your data into training and validation set which is machine learning 101 and you can use that to develop the model and then the validation set to test and refine it. Although please make sure that any of these ML models should be reviewed and validated by human experts or I say human experts these are like people who understands the business to ensure that they align with business needs and security policies. Another great use case for AI and ML implementation here is the continuous learning use case. So as users behavior change and the organizational evolves continually feeding new data in the ML model to refine and adapt rules over time because role is not a once and done type of thing. It is a continual process in which you would have to invest your time and energy and money into making sure that your role model is up to date is really doing the things that you needed it to do and adding value. The value that was identified after the first mining activity was carried out. So continuous learning and also anomaly detection I think is another use case. So anomaly detection monitored for deviations from established patterns prompting reviews or adjustments feedback loops is another example. So implement a feedback loop to collect feedback from your administrators and end users on the accuracy and ineffectiveness of the proposed rules and use this feedback to modify or update or refine your ML model and improve the role predictions. Now in this phase the most challenges that I have seen obviously is the stakeholders have to invest a huge chunk of their time. So there has to be an executive level buy-in to carry out this activity. I hate to use the term but do not boil the ocean is a very apt phrase start very small. Data quality so any manual or automated mining that you carry out really depends upon the accuracy and effectiveness of data and incomplete or inaccurate data can lead to misleading rules. Complexity is another thing if you're using an ML based model it could get very complex very soon and this would require expertise in both access management and machine learning which is quite a niche skill set and interpretability which is like ML models specially complex ones can sometimes act as a black boxes. So it might become very hard for an I.M. engineer to understand why are certain rules being suggested. So there are tools out there in the market very promising tools which enhance and streamline role mining but successful implementation requires careful planning continuous refinement and collaboration between AI experts and access management professionals and business subject matter experts but there are also benefits of using ML in role mining process. So automated role discovery, scalability, dynamic adaptation, predictive analysis, anomaly detection some of the things that we spoke about earlier these are all the benefits that we have. And then you go into another phase after this role discovery and everything that is carried out you now have your defined rules in which you create
your maintenance and business as usual fees. So you define and implement your processes like role lifecycle and governance, role creation, modification, deletion, role certification, regular audits, all of these things are actually defined and implemented during this phase. Thankfully for role-based access control in the cloud, most cloud providers like our senior AWS or Azure or Google, they have their built-in RBAC systems. So I think in AWS it is user IAM roles which can be assumed by users or AWS services and permissions that you find in policy documents. For Azure, if I'm not wrong, it is Azure Active Directory and role assignments is used and for Google Cloud, it uses cloud IAM with predefined rules and the ability to create custom rules. So the concept is pretty similar across the cloud platform but use their out of the box RBAC systems. And then some of the best practices would be regularly review roles and permissions. If you have automated models that great, but make sure that as business evolve, so do access requirements and you are regularly reviewing it. Use logging to track who does what and cloud has really been embracing here. So AWS Cloud Trail or Azure monitors are couple of services in AWS that I could think of which really helps with this. And then use automated tools like Terraform or cloud formation to define and deploy roles. Some of the other things that you need to consider is, you know, include RBAC as a part of your IAM strategy. Right. So quantify how RBAC enhances your security posture so that you can get the buy in from your leadership. Define the role matrix like you know, start with really broad roles and refine as needed, which we spoke about when I gave you the example of do not boil the ocean. Education and training is very, very important here. So use this opportunity to teach user about not just RBAC, but also IAM in general, because roles are at the end of the day an abstract concept. They only exist within the IAM system. Automate as much as you can and stay updated. There is feedback, there is A-back, there are so many other things or so many other ways of doing this. Even with a P-back, there is aupar and Xaml and so many things. So the devil is in the details there, but stay updated because this space is evolving very quickly, very fast and I'm very excited to see what is next. Some of the pitfalls that you need to avoid is over complexity. Too many roles can lead to management challenges. So strive for balance between gravity and manageability. So there is no rule of thumb, but try to keep the roles at a minimum and do not try to solve for all cases. Avoid roles that are no longer in use. So stale roles they can become potential security risks. Another thing which is sometimes glossed over is documentation. Nobody likes to do documentation neither do I, but always document roles, permissions and rational because it aids in audit and future reviews and not involving stakeholders. You cannot be successful with an R-back program if you do not have stakeholders not just being there but also supporting you. So they should be championing this effort as much as you do. So excluding key personnel from the decision making process can lead to much requirements or resistance to change. So make sure that they are behind you 100% include them as early as possible in the process. Try to understand and solve for their problems rather than just rubber stamping that we do have an R-back program in place. And this is where how are you measuring the success of your R-back program really comes into picture because I have seen too many firms doing it very badly or maybe starting on it and not being able to scale it to the level that they want and then they just continue to use the same legacy roles that they had because it is hard to reinvision that role based program. So some of the key KPIs that I would suggest and you would obviously have yours based upon the business table that you have is on boarding time. So identify the time that is taken to grant a new employee or contractor the necessary access and a well implemented R-back should reduce this time. So quantify this on boarding time and then identify role modification time. So the time it takes to update a role or change user roles and make sure that shorter time is there because the shorter time indicate more efficient management processes. Compliance matrix what is your audit pass rate and track the number and severity of audit findings related to access control and with this successful implementation this number should go down. You get your policy violations, monitor the number of access policy violations, quarter over quarter and a decrease over time indicates success. So other KPIs are number of unauthorized access incidents or number of overprivileged users. Both of them should go down ideally. Operational matrix would be role change request. If you are getting a ton of role change request that means roles are in well defined or organization is changing rapidly. Role approval time the average time taken to approve or deny role assignment or serious. User experience matrix carry out that survey so this might be very qualitative but periodically surveying users about their experience and access processes and improvement in satisfaction can indicate R-back success. You should do it for your IN program as a whole just because you know it is very central to how your users operate. You need to have a feedback management system in place and this user satisfaction survey for R-back could be a part of it. Make sure that your users do not have feedback fatigue but you have very targeted surveys for them to provide their feedback on. Then the help desk tickets. If the access related tickets are going down that means your R-back is on the right path. You can also look into role management matrix like number of stale roles or role density. So that means role density is like measure the average number of roles per user. If this number is too high then that would mean that role might be too granular. Now you might ask me how do I identify it's too high. Think of it as it manageable and if it is not then it is too high. And also your pattern analysis or create an overlap analysis of the roles and that would give you some good indications as well. So what I have done in the past is I have created a system in which I am measuring role 1 to role 2, role 3, role 4 and then role 2 to role 3 and 4. So this loop was running through and identifying the amount of overlap that each role had. And that told me that I have too many similar roles in my organization. You can also have cost matrix in place like administrative cost of managing and maintaining access controls before and after R-pack implementation your call center would be able to tell you the cost of one call and that would give you a starting point of creating this financial model. And then the training cost. It says the cost associated with training users and administrators about the R-pack system. So your security awareness and training team might be able to give you some associated data with that. You could also have adoption and usage matrix.
You can also have business related matrix like operational downtime. Excessive, there is a reduction in downtime due to access related issues or their business processes have become more efficient due to streamlined access control. Now this is very hard to quantify, but, whether it is a good matrix to have if you can have it. And lastly, it is essential to benchmark these matrix before implementing the RBAC program. Providing a clear baseline to measure against regularly reviewing and comparing these matrix over time and giving a comprehensive view of the RBAC's program's success and area of improvement is must because it's not a one and done thing. You have to carry it out continually and you need that stakeholder by and these are the KPIs based upon which you might get a continual stakeholder and executive by. Right. So just something that you could do basically after implementing your RBAC is ongoing review and optimization, monitoring and auditing. Continuous training, integrating with other systems, feedback, loop, scale and adapt and things that we have spoken about. So continuous monitoring, refinement and adaptation are essential to monitoring the system's integrity ensuring compliance and meeting the organizational evolving needs. Before we go into another section, plan for the future in terms of budgeting ensure that there is budget allocated for the ongoing management and future enhancement of the RBAC system. Because every day that you're not looking at an RBAC system, it is getting stale. Whenever we talk about RBAC, we also talk about feedback and A-back which is policy based access control and an attribute access control. I have some very strong thoughts around both of them. So hopefully we'll pick them up in the later episodes if you folks would like to listen to that. But at a high level, understand this as a rule of thumb that in any modern I am implementation, RBAC, A-back and P-back often coexist and complement each other. So your company might start with RBAC for its simplicity and then incorporate A-back or P-back mechanism or it could have RBAC for course, grain, and P-back or A-back for fine grain access control. So for example, a user might have access to a resource based upon their role, which is RBAC, but additional attributes like their location or the time of day might further dictate their access level which would constitute A-back or P-back. So while RBAC focuses on roles as the primary determinant for access, A-back and P-back extend and generalize this by considering a broader range of attributes and policies. And choice or combination of these models depends on the specific needs, complexities, and context of the organization. Now for role mining, even if you don't want to create your own machine learning algorithm, there are multiple tools in the market. So most of the identity governance and administration tools do have the role mining capabilities like tailpoint identity now or tailpoint identity IQ or a call identity governance. Even cyber arc has some capabilities. One identity manager, I've heard good things about Savian recently, tailpoint has come in with some of the AI capabilities. IBM security identity governance and intelligence, IGI is a good tool. RSA has an semantic have some of these functionalities, HITACHI and Omada identity sheets. I think are pretty good. And I also know of this tool called Sconflexes and I've spoken to Rahul Shah who is the owner of this company. So this is a standalone tool for role mining and they carry out some of the other things as well, which can integrate with your identity governance systems. So I've heard good things about that as well so you can check it out again, not being paid by Conflicts is just something that I've seen in the past companies evaluating. Now when you're evaluating the role mining tools, what are the things that you need to keep in mind? A, your identity governance tool do not have to be your role mining tool. You might have the best identity governance tool in the market, it could absolutely suck at role mining. So if you need a different tool, you need a different tool. But the things that you need to look out for are the integration capabilities. So ensure that the product can seamlessly integrate with your existing IT infrastructure. It has the capability to integrate with your identity governance system, it has the capability to onboard get those entitlements in an automated manner. The scalability, the tool should be able to handle the size and complexity of your organization. So during POC you might want to do it with five entitlements, but you might have a million entitlements in your system and you need to make sure that the tool is able to handle that size. This is a very business focused program, so make sure that the interface and workflows are very intuitive. This is very important. It should allow for customization and it should have a strong, Windows support and an active user community because you would have things that you would like to learn along the way and a strong support and active user community helps them out. So you have your KPIs, you have your rule of thumbs for evaluating role mining tools, carry out a proof of concept or maybe ask for a trial period, check out what are the type of roles that are being created. Do not start with the most complex system which in my experiences have been mainframe systems super complex to carry out role mining, but do not start with systems that have got like 15 entitlements or 20 entitlements. Start with something which has got a moderate amount of complexity and then the roles that are created for that system or start with a department that has got, so do not start with like IT department that is such a mess, but do not start with like law as well because that's super clearly defined. So start with a department which is partly messy and carry out your top down and business in birthright and IT role analysis based upon the, so for your business or birthright focus on organizations which are partially messy or a little messy and then for systems which have got moderate complexity and moderate amount of entitlements and user base as well. So you don't want to have role mining on a system that has got just five users because it won't give you that is your role mining tool could enough. So based upon your KPIs and based upon the criteria for evaluating role mining tools, these are some of the things that you can look into. All right we are at almost 50 minutes. I do have some packing to do because my flight is tomorrow. I will try my best to record a podcast next week, but just in case I get delayed I will cover up for that in the following weeks. I hope you enjoyed this. Rolepage Access Control is something that I am very very passionate about as I am about and basically everything identity and access management. So first of all thank you for listening. I really appreciate the time that you gave me. Please reach out to me while LinkedIn. I absolutely love it or you can also email me at theidentity
[email protected]. So any channel that works for you, I am always happy to engage and talk to you about this. If you have anything that I did not touch on it, if you have a recommendation for a tool that our listeners can also benefit from, absolutely let me know. So thank you once again. I appreciate you and your time and the feedback for the last episode which was absolutely awesome and I was very surprised and humbled. Until next time this is Rohit, your identity navigator.
[BLANK_AUDIO]
PodcastTranscript AI