Gain a Unified Business View With Enterprise Identity Management

Hello, I'm Richard Hill, an Analyst at, and today we're having a webinar about how to gain a unified business view with enterprise identity management. This webinar is supported by one identity. And joining me today is Jen E M E a presales manager of one identity. And before we start, heres some quick information about Umer Cole and some house cleaning notes as well. And before we jump into the topic of today's webinar,
As you have may have already noted, we have a series of upcoming virtual events, all very modern format with panels, presentation, keynotes, and much more. The next upcoming virtual event is the privilege access management, Pam for enterprise, which is on July 7th, where Cole and other experts in the industry will present information on why companies need Pam and how Pam helps to prevent security breaches, credential, thefts, etc. By defining and implementing the right strategy. Then on July 16th is the customer identity and marketing automation virtual event. We could hear from experts from different industries, dealing with IAM and marketing automation, as well as other Siam use cases,
Future of identity, self sovereign identity and verifiable credentials is on August 6th, which is a virtual event dedicated to self sovereign identities and the future of identity. So there are a lot of virtual events as well as other types of events that you could see during the, throughout the year. So please take a look at our website, research, blogs, post and videos, and now for some housekeeping, everyone is automatically muted. So no need to worry about muting yourself. We'll be recording the webinar, which should be available by tomorrow on the website. Also, we will save some time at the end for questions and answers. The go to meeting control panel has an area to type in your questions at any time in which we'll answer during the answer question and answer session at the end, with that, let's look at today's agenda. I'll start out by talking about identity governance and administration with some general overview of what it is, why it's needed and how it's continuing to evolve through more integrated IGA solutions. Once I'm done, I'll turn over the webinar to genus, to, to talk about how one identity can help companies bring SAP accounts under the management of the same IAM you use for the rest of your enterprise. And then finally, as I mentioned, we'll save some time at the end for questions and answer sessions.
So I thought I could start by looking at the KU Cole identity and access management reference architecture. It consists of a variety of different areas where building blocks, which could be considered core parts of identity and access management under the categories of administration authentication, authorization and auditing. And on top of those core identity, IAM functionality are what we consider extensions to IAM such as the user behavior analytics, which appears under the auditing category. I am is further extended by adding features that are adjacent to the different areas of it, like tie into an it service desk capabilities or SIM or some kind of security intelligence, or even API management and security since more and more security services are exposing their APIs. So these are some of the areas of specific relevance today's topic.
I also think it's important to understand some of the things that are increasing pressure on organizations. So compliance means conforming to the different rules, such as adhering to an organization's internal policies or external laws and regulations. This could be HIPAA and healthcare SOS from the SBIs Oxley act to guard against fraudulent practices in enterprise user data protection like California, C P P P a or the European GDPR, or even ex internal organizations use of information security standards like ISO 27,001 or other ISO documents in this series as best practices. So how do you show that you're in compliance? You could show that you're in compliance through an audit, which is an inspection or examination of what you're doing or did to be compliant with those rules. This could be done through showing controls or your policies put in place access records or other types of artifacts. So in the end, it's the actions that matter. And you mitigate these compliance risks by adding compliance related capabilities on top of those basic security controls of IM. So to summarize organizations really need to ensure that they are in compliance with all the different rules, laws, regulations, and of course, you know, passing those audits by putting the right security controls in place and then using them.
So over the years, there have been a number of different types of environments that we need to start working with. So these changes have been increasing as well. So on premises were traditionally, the it environment is run on premise, and then we started seeing Federation hubs or bridges to start to appear. And this extended the reach of where identity and access controls really resided in allowing for the extra secure exchange of user information. And then cloud services gave organizations new options for it really motivated by the businesses need to increase their it flexibility and scalability while of course reducing cost. And now because of the hybrid environments that span across on-premise cloud and even multi-cloud environments, we're beginning to see identity APIs becoming available, driven by that need to meet those emerging hybrid requirements. So that landscape of the different kinds of environments hosting and organizations, applications, and services has expanded, which of course causes a lot of complexity with accounts spread across different environments in a system of systems type of pipeline means that there could be many different applications and services that a given user may need to access each with their own user accounts or roles or entitlements to consider when it comes to keeping track of all the different controls in regards to ensuring that in compliance and audit.
So some common symptoms of ineffective IM and identity and access governance that you may experience at your own company is when users start to complain when there's maybe too many ways to request access. If you have several different portals, you need to access to access the different applications and services, then you may have an issue when new applications or services become available, such as new cloud type of targets and those connections aren't available. Then this may cause some manual workarounds to get them to do what you need them to do. And then there's always the lengthy user onboarding process, and then not being able to deal with more groups of users could be a frustration as well.
And when going through re-certification and there are many users with dozens of different entitlements to go through, and you really don't have a clue what all these different entitlements really mean can make that re-certification campaign kind of bumpy and not really well liked by users and then incomplete and inconsistent role models can lead to situations where people get frustrated because of these, these things become too complicated to do so. We have a variety of challenges in IM and identity and access governance, that point to what can be avoided when you do access governance the right way. So where does IGA fit into all this in the, I am reference architecture, IGA covers both the administration and auditing categories here on the left, addressing those joiner leave mover processes with identity provisioning, life cycles, and then having a strong access governance of who has access to what entitlements for example is really what's important here.
So the identity provisioning part of IGA is really about provisioning identities and access entitlements to those target systems. This includes creating and managing accounts and connected target systems and associated accounts with groups, roles, and other types of administrative identities, entities to enable entitlements and authorization in those target systems. Identity provisioning is also about automating these tasks based on defined processes for creating or updating or even deleting identity related information in those target systems. Again, the key capabilities here are those connectors to the target systems, account mapping and identity data modeling, given it that flexibility, but centralized data model, workflow capabilities to support those requests and approval processes, as well as automating the management of identities and access the user self-service interfaces for password resets and users being able to manage their own identities, for example, and then things like access request management and delegated administration features are also needed.
When you look at access governance specifically, we need to consider some other things here. So we need to access to all the systems and, and really this should cover as many systems as we can across all deployment models. We need to connect to the systems where no matter where they reside, but we also need the depth or the deep insight into how these connected systems correlate. And this is where the technology can really help us to do things better because this insight on how things relate and where the problems occur, really takes some kind of analytics or intelligence on what to do, which in the end makes things simpler and better overall. And then of course, all these things need to be effective and efficient. So in the end, you need to deliver also focusing on what's really required and again, to automate where automation could be used or make sense.
So some important features that you will find in an IGA solution that you might want to consider, of course, is as we mentioned, the identity provisioning, the life cycles, we talked about the jar leave mover processes, the ability to provision identities, also access entitlements, and other identity related information in those target systems. Also capabilities to consider is the ability to identity stores, data modeling, and mapping between the different systems, as well as the ability to handle different identity types. Another key component of IGA are those connectors, both depth and breadth, which are the capability of handling the different applications and services that you may have across the different environments. So you may want to be able to access, you know, those directory services or even legacy mainframes in the capabilities, especially when it comes to connecting to complex systems, such as SAP environments, which we'll hear more about in this webinar.
Connector breadth also looks at the support for standard codes, cloud services, connector, depth, further customization capabilities for connectors. So those connector toolkits and the ability to use popular or even relevant standards are some examples, access and review support. This supports the auditing and ensuring compliance such as, you know, having an integrated access compliance capability that supports activities like review and disposition of user access requests, certification, definition, and campaigns, as well as access remediation when violations are found, also looked at is that segregation of duty controls to identify track and report and even mitigate those sod policy violations as part of that overall integrated risk management and increasingly IGA solutions are providing identity and access intelligent capabilities that provide business related insight, supporting effective decision making and potentially enhancing that governance process capabilities can include advanced features such as machine learning techniques that enable pattern recognition for process optimization or role design or automated reviews. Anomaly type of detection are also considered beneficial.
And the use of automation is also increasing as organizations seek to become more efficient, which could include workflows and orchestration of security processes. And then finally the centralized governance visibility, which is really the extent to which identities and their access under governance control can be viewed in some kind of a consolidated or single pain view, such as a dashboard of some kind and also having access to reports and other auditing support type of features are typically provided as well. So identity governance and administration is primarily access governance, and I did identity provisioning together. So IGA realized heavily on those connectors for both the depth and breadth into those applications and systems as well as solutions ability to utilize the user groups, roles and other attribute information that may be available. For example, using information within its identity and access capabilities can help identify the associated risk and provide useful insight that could help improve in organizations compliance and overall security posture.
Finally, you know, having that centralized single pane of view, as I mentioned, and their access to applications and services across all the different deployment models, and then having that ability with metrics and insights to make it easier for organizations to get that grip on compliance and associated audits, some aspects of IGA integration to consider, of course, the connector's ability to integrate with target systems is an essential capability, which I talked about already in this area. We want to consider connectors ability to do bidirectional interactions with systems and of course communication channels between connectors and target systems. You wanna make sure those are secure. Something else to consider is the IGA solutions ability to integrate with identity sources and performance and its performance impacts, which could be better or worse. Also how well is customization supported through data modeling and mapping tools that are usually provided with these solutions. Other considerations might be the ability to integrate with existing Iams services such as additional IM or identity information that could be used also within that compliance scenario and being able to use well accepted standard pro protocols formats as well as frameworks is important too. And when it comes to customization, you wanna make sure that the ice GA solution is able to support both developers and DevOps processes as well as well.
So some benefits of identity governance and administration are the ability to provide visibility to user access and ensure compliance through anomaly and outlier type of detections, as well as identifying those orphaned accounts, having certification campaign progress reported in trends, audit support to demonstrate in organization's compliance regarding internal POS policies or those external laws and regulations. For example, support for resiliency through mitigating those risks and improving that security and providing efficiencies with workflows and automation that could help improve processes with faster onboarding or off onboarding, enabling self services as examples. And now I will turn over the next portion of the webinar to Jen.
Thank you very much, Richard. I will be looking at how organizations can gain a unified business view and how this can be implemented in practice and provide insights into one identity managed support for SAP systems. Now, what are the challenges did we encounter in customer world specific to SAP is complex enterprise applications like SAP are difficult to model. For example, lots of applications have users in groups, groups provide access to resources and users are put into groups to grant this access. This is fairly easy to model SAP is however much more complex SAP has groups and users through, but it also has profiles and roles and menus and transaction codes trying to boil these complex relationships down to users and groups is close to impossible. This leads to a very common behavior in organizations to divide the world into SAP and everything else. We see often enough that organizations segregate or create silo approaches from the management standpoint, since SAP is their core business enterprise application, they concentrate on SAP, but with growing internal and external pressure from compliance perspective to meet laws and regulations like pointed out by you, SOS and GDPR and others, a unified business view is a must, but many IGA solutions don't have a rich support for SAP.
They treat SAP like any other target system and reduce the SAP world into simple users, groups, and their relationship as in user member of group, et cetera. This is like trying to fit a small size t-shirt where next to large size t-shirt is actually needed this gap in the man map between the SAP and non-SAP world is also present. Present in the IGA world. IGA solutions are heavily influenced by the relatively common but easy model of directories with users and groups and cannot absorb and reflect the very rich model of SAP with profiles, roles, menus transactions, and their complex relationships with each other in the data model. The lack of understanding and insight constitutes the basis for segregation and creation of silos. Customers want solutions that understand their SAP world. And how about if we add cloud systems to the equation, do we bring yet another silo into play the silos approach results in multiple solutions to manage identities with the users accounts and permissions?
There's no single overview as it would be needed to have a holistic view on the identity with all his accounts and permissions in a heterogeneous hybrid world, implementing regulatory requirements across different solutions. And being able to prove this in an audit gets more complex processes and platforms have to be managed and developed redundantly. For both words, SAP and non SAP business users have, have to either learn yet another interface for request something or the central corporate Porwal needs to integrate yet another solution to lead the end user believe that he's only accessing a single solution. As you pointed out earlier, another topic about IGA diseases that you might have hit either way, the maintenance, upgradeability management of the platform and the governance of identities under access will be unnecessary complex. The enforcements of segregation of duties like controls will be, if not impossible, rendered very difficult with the siloed approach. It is very likely that not even the concept of identities and their relationships between the different solutions conform to each other, like do all the siloed systems have the same notion of master up identities. Can an identity have more than one account assigned to it? Where is the S OD check going to be executed the identity master or sub is it the account are the result of the S O D checks actually transferable?
So when we consider the S three P ecosystem, we will see different solutions like an offerings like on-premise cloud hosted or full software as a service solutions. But the predominant view or understanding at the moment still is when we talk about SAP, that the SAP on premise world with R three ECC and S for HANA is when we, what is relevant. This is where the mental gap already starts between the SAP and the non-SAP world. And we haven't even looked into cloud or hosted SA software as a service solutions here. This is where the SAP world cannot simply be transferred into the non-SAP world with its simply user group. Be of the world in the SAP world. User accounts are created individually on an SAP client. A client is a tenant, an instance of an SAP system, sharing common install, base and modules with different custom tenant specific data.
If an identity needs access to different clients on an SAP system, he will require different master records, different accounts on each client and different permissions on each client. So to perform user administration first, a user master record for each user needs to be created with which the user can log on to the SAP system, using the user master record one or more roles or profiles for that matter can be assigned to the user. These profiles or roles determine the activities in the user menu and which authorization the user has house, as already mentioned, user master records are client specific and, and separate user master records for each client in the SAP system need to be maintained in large scale SAP and deployments with multiple SAP systems and clients on these systems. Performing user administration with native SAP administrative tools will become a demanding task, especially when you need to authorize the same identity on some or all of these SAP systems and clients to simplify the user administration in the pre identity management area, the central user administration system was introduced to distribute the user master record from a central system to child systems.
But how are users authorized in an SAP client in an SAP client? SAPs authorizations is short for advanced business application programming, protect transactions, programs, and services in SAP systems from unauthorized access, the administrator assigns authorizations to users to control which actions each user can execute in the SAP client to, to access business objects or execute SAP transactions, which are both protected by authorization objects. User requires corresponding authorizations. The authorizations are combined in so-called authorization profiles that is associated with role the user administrators then assign the corresponding role or authorization profile using the user master record so that the user can use the appropriate transaction for each task roles and profiles can be used to sign authorizations to use users profiles. As main carriers of authorizations can be generated single or composite profiles, composite profiles contain other profiles, composite profile assigns all the simple or composite profiles. It contains two user and the single and or composite profile is then associated associated with a single role, which itself can be associated with a composite role leading to several levels of nesting. Now transferring the several nested levels into the data model is a huge challenge for IGA solutions with fixed and inflexible data models.
What now, what should a comprehensive solution provide to address the challenges described before? First of all, it should understand the very elaborate data model of the SAP world. It should understand authorizations, authorization, profiles, and roles and their nesting. It should have, or provide flexible data model that is already SAP ready, the SAP world with its clients and systems, and their relationship must fit into the data model natively. If the SAP world does not feel like a foreign body in the IGA solution, but it perfectly is perfectly reflected as a native object in the IGA solution, there will be no need to segregate or build silos for the non-SAP and SAP words. One identity manager does provide this level of support for the non-SAP and SAP words. One identity managers, common data model, unifying SAP, and the non-SAP will, will bridge the mental gap, talked about earlier and provide a common language for the different roles, with a single solution that is capable of managing SAP users, non-SAP users and granting access to SAP and non-SAP systems, a single view on an identity and its accounts and permissions throughout the enterprise will be available.
Meeting laws and regulations and achieving compliance will be made easier. Requests can be made from a central interface and the business use only required to get used to only one more tool. Not several. When we consider that SAP is not only a target system, but can itself be a source system for authoritative data. We can read HR and org management data from SAP. One identity manages unique support for that HR module with its data model is again, unparalleled and provides deep knowledge of the SAP system provisioning to the clients can be automated based on rules. And the master record can be derived from the identity record, actually coming from the authoritative source, which itself can be an SAPR client. Once the silos are decommissioned and everything is centralized in a comprehensive and powerful idea solution, like my identity manager, centrally managed policies and workflows can be implemented.
There's no need for redundant policies or workflows anymore. Risk considerations can be managed centrally incorporating the enterprise's most crucial business applications. The entitlement catalog that is available for end users of one identity manager contains roles and profiles are next to available for request the extended catalog can be used in business role management, providing a more comprehensive role management containing SAP. So the SAP roles don't need to be maintained outside of SAP. Finally, one identity manager will extend the organizations' reach from on premise to cloud solutions as well. This is not only restricted to SAP cloud solutions. Other software as a service solutions can be easily managed in one identity manager as well. It provides integrated support from OnPrem and or cloud source SAP systems to OnPrem and cloud targets. SAP systems SAP on premise and cloud solutions will be more manageable from a single solution. And business users will be enabled to use roles and profiles for business role maintenance.
When we integrate SAP systems, you also need to consider what SAP systems are that SAP systems are by nature. Very large systems. Oftentimes customers have large number of systems with large number of clients per system. And these clients need to be managed by one identity manager SAP on premise ecosystem with hundreds of SAP systems is not uncommon. Identity governance and administration is needed for production and non-production systems as well. Companies can have several hundreds of thousands of employee records in their HR systems, active employees, as well as inactive employees. Some customers don't delete records of employees that have left the organization. Others still need the records because they still offer benefits for retired employees and therefore have to keep employee records in the HR system. It's also not uncommon to have employees that have more than one work contact with, with their employer. And oftentimes customers also maintain a record for external contractors in their HR system.
And when we look into beyond premise SAP system, as a target system, the amount of information to be managed is even higher. We often encounter hundreds of systems, which clients as much directly manage or manage via the central user administration of SAP. Given the number of employees in large deployments multiplied by the large number of systems and clients and to different business modules that are available. SAP deployments easily end up with several millions of SAP profiles and roles that need to be managed. If you further drill down the authorization objects in an SAP system will in the range of tens of millions. One identity manager offers horizontal as well as vertical scalability to support the numbers. Job service can be grouped in load balancing configurations or groups dedicated to systems or clients and, and distribute the load and reduce the synchronization time. But one identity does more than just throwing hardware at the increased load.
One identity connectors have sophisticated filtering and Delta syncing capabilities and different configurations can be scheduled to synchronize different subsets of the necessary information. According to the update frequency of that data subset, in some instances where due to the underlying role model up to 70 million of SAP roles were expected in a client and only 10% of which were actually expected to be assigned to accounts. Synchronization time can be reduced significantly, but this is only to get the data into the IGA system, into one identity manager. The data needs to be managed and made accessible through the entitlement catalog here. Again, one identity manager combines architectural scalability with a sophisticated approach, the categorization of objects in the catalog, the filter of relevant users to catalogs. So only selected users see selected parts of the catalog and, and then the filtering and sorting options in the web front end for end users together with a deep understanding of SAP authorization model, combined with the support for sub SAP business logic, a key to manage numbers and scale. So this enables our customers to leverage SAP, specialized workflows and business logic. When we think of SAP roles and profile as the most target system and entitlements, we might or might not have a naming convention, they might or might not have speaking names that are understandable by business users. And even if they have names, so description understandable by business users, oftentimes business users don't know the roles or profiles they need in SAP system. Sure. We can provide the information and let business users filter and search based on names and descriptions of tax.
But this is not how most of the end users work. They are used to run transactions. They know they need a transaction like FPR two or FP zero two in the finance model for them, the transaction is more or less the authorization they talk T codes transactions. So what is more intuitive to them than to search for a transaction in a catalog and request access to that transaction one identity manager, support business users to request their transactions without knowing the specific specifics of which and how many roles or profiles are providing this transaction. The business user just requests the transaction. Then in a multi-step workflow, a group of people with domain expertise, knowing the entitlements permission model authorizations in SAP gets a filtered list of roles or profiles that will be pro will provide the desired access. They can now select the best role or profile based on the information of the requester and their knowledge.
The approval of the business approval will be for the SAP role or profile selected by the domain experts, but will grant the access that the business user requested the request and knows his transaction, the approver approves, the transaction request, but ultimately approving a SAP role request that an expert has picked, of course, various modification and alterations of this business process are possible just to add one. The business user does not even have to know about different SAP systems and fines. He only knows he's working on an SAP system. If he has only a single account or has requested a transaction that is only available on a single client, like the finance transaction quotes. I mentioned earlier, all the suggestions and selection process in the background can happen automatically and pick the right or, or provide the right permissions, entitlements, sorry, profiles and roles that the domain experts can pick from. When you look at another SAP specialized workflow, it's the firefighter scenario where emergency tasks need to be performed by an admin in a controlled way. One identity manager supports this scenario and can leverage an existing implementation like safeguard or complete support with this out of the box functionality.
One identity manages privileged access governance module allows the interaction with the pump solution to retrieve the privileged user credentials, or if it is not desired, a ed session can be provided where no password has to be disclosed, but the session is made available to the firefighter. The firefighter can request this one identity manager and will get the needs access if no existing pump solutions is available, or the integrations of wanted one identity manager can be used to authorize the user directly on the selected system by assigning him the required roles and profiles in that SAP system for a predetermined time like two hours or four hours in both scenarios or without pump solution integration in any case approvals are counterproductive. So if something is an emergency and the fire needs to be fought, as the name suggests waiting for approvals will only delay the problems resolution.
So how can one identity manager support this SAP specialized workflow and still allow customers to be compliant? Several aspects of the product will support this, the catalog that will only be, or only make products like the firefighter permissions or the firefighter account available to the, to the selected group of people, ATEST stations, recertifications that need to be run periodically to verify that this group of persons still need access to the firefighter product. Mitigating controls like security training, periodic tests that these persons have to take and the retrospective approval to tied up. What do I mean by retrospective approval since pre-approval is counterproductive, the system will assign the requested product, but immediately trigger an exception at recertification effectively being a retrospective approval. Having all the deep insight knowledge about SAP enables us to perform SAP, optimize sod, verification, and enforcement. So how are some solutions doing compliance and sod checks, compliance, rule checking, segregation of duty checks and company policies are necessary to ensure compliance.
Just a few examples for simple rules are an employee may not obtain to entitlements a and B. At the same time only employees with a particular department can have a particular permission. Every user account must have a manager assigned to it or a disabled, temporary or permanently. It doesn't matter. A person should not have any enabled account associated with him. So SAP provides a governance risk and compliance module for rule checks this from framework execute rules, which have to be configured upfront within SAP. It provides some additional features like the firefighter as well, but the main part is the OD rule and engines rules engine. The main disadvantage of the GRC module is that rules are executed on a single independent SAP account without any reference to business dependencies within the SAP system landscape. Any relationship to other SAP accounts, such as subordinate, superordinate, or sub employee identities is not included in GRC rules calculations.
Therefore the risk is high. That violations will not be detected in a heterogeneous world. This is not enough. One identity manages rules on the other side are executed on the identity level, the master identity, and are all sub identities with all the accounts on all the systems are included into the calculation. The check is being done natively on the data in one identity manages database. When we revert back to some of the examples and employee may not obtain two entitlements a and B at the same time, we now can make sure that an employee does not have entitlement a on client X and entitlement B on client Y at the same time. So cross client or that an employee's account X does not have entitlement a and the same employee's account, Y has entitlement B on the same system at the same time. So split across accounts account centric approaches will miss these combinations by their inherent focus on the account, or very complex setups will be required to model this in any way.
This will be a very difficult task. Now on the other side, having an identity centric, sod engine will simply not be enough to expand, to reach of the OD rules into the asset P vault either the sheer number of profiles and roles. And the fact that profiles are being generated during the role design will make it impossible to rely on simple rules, like put role a in conflict withdrawal B in the SAP world, since profiles are being generated, saw the names. And since the actual permissions come from the authorization objects that are being used in the authorization profiles, the only feasible approach is to check exactly on that level. You don't put profiles or roles in conflict. You put activities on fields with specific values in specific transactions, in conflict to other activities on fields with values like activities, zero one on field B KRS with value 44 is in conflict with activity zero two on field KT OPL with value ten one identity manager will match all profiles and roles that match criteria, whatever the names are and how they have been sliced and, and, and will find the sod violations, unifying the business view and the business roles.
So the SAP's ecosystem we have talked so far was the on premise. However, the SAP ecosystem is not only, or does not only consist of the on-premise systems. SAP has lots of software as a service offerings that are more and more being adopted by the customers. How is this supported with one identity manager? How is the unified business view extended to the cloud SAP cloud applications integrate with one identity manager with one identity manager styling connect, which is a cloud based connector microservice offering. It is designed to integrate with one identity manager through a multi-tenant cloud platform. This service provides a range of out of the box connectors to software as a service applications to manage user accounts and rights based on requests executed within the IM solution. One identity style in connect translates, identity management platform, scheme version to compliant requests, interest based API calls.
So or web services based API calls, depending on what protocol, the actual software, the service platform uses across your entire it infrastructure, covering all the places where your business have user accounts, the connectors create update, delete, or reactivate accounts and import data from the accounts for reporting and governance. Aside from supporting the corrupt operations for using groups, styling connect can synchronize HR related data and information. For example, employee data, business units, companies, departments, locations, divisions, and cost centers into the identity management system, and has the ability to write related attributes like usernames for numbers and emails back to the HR systems.
So combining all together, one identity manager unifies the on-prem and cloud-based SCP ecosystem with the non-SAP world. It essentially provides the ability to centrally visualize and manage those on-premise and cloud SAP. So systems alongside the non SAP systems, the segregated and siloed approach is not necessary as one identity manager, not only provides unified identity lifecycle capabilities of provisioning of users entitlements. It also allows for SAP compliance and GOs to be implemented in cross-platform and century summarizing it. One identity manager enhances SAP compliance and governance with a cross-platform view that merges the SAP ecosystem with a comprehensive view of non SAP resources, best fit for companies requiring strong governance for SAP scales to the largest and most complex SAP organizations delivers fine grade SAP object management required for efficient, secure, and successful operations understands and provides identity access go for the difficult to manage aspects of SAP. So transaction codes, process codes support for custom Z tables, and other attributes provides SAP optimized, sod verification, and enforcement and delivers SAPs, specialized workflow and business logic within enterprise governance. The SAP connector is certified by SAP and provides the ability to be backed out of SAP systems if it should not be needed. And so today's discussion was focused mainly on, on identity manage and SAP. However, the unified business view and compliance applies to other environments as well on-prem or cloud. So thank you very much. And handing back to Richard.
Okay. Thank you, Jen. So now we've reached the question and answer section of the webinar. So as I mentioned, the recording of the webinar and slides will be available on the website also within the go-to meeting chat window, you could type in your questions at any time and we'll answer those. So let's take a look at what kind of questions we have. So it, it was mentioned that a question of what is the largest number of SAP employee accounts that you've experienced. And then kind of as a follow up question is, you know, what, what kind of synchronization times have you experienced as well?
Okay, thank you. That, that's an interesting question. So we have implementations and one specifically where we have seen 1.4 million of employee records in the SAP HR system of which 260 K roughly we're active employees, and without about the same number of accounts to be managed in the SAP system, the synchronization time, of course, the initial sync takes a bit longer. Everything needs to be set up, but that's, that's ramp up phase. However, the synchronization of a new employee record with subsequent provisioning and assignment of birth rights takes about half an hour.
Okay. Thank you. Let's see. Another question is in that you had a slide about firefighter scenarios. So what happens to those firefighter logs?
So there, again, the question is which solution or how the support is set up, whether we have a Pam solution or we are going through or supporting it without a pump solution, if we are, for example, doing it with a pump solution and with a session, then our safeguard solution is capable of, of session recording. So that everything that is being done will be recorded and can be reviewed and audited. If we go for the password case, or if we go for the entitlement assignment case, in both cases, the SAP internal locks, audit logs like STO 3m or SST a D transactions that will provide this information will be still available. So when it comes to logging, actually the same logs that you can retrieve from the C SAP system natively will be available. When, when, if you go through an session management P session management system, you will have additionally, the locks, the locks and, and, and the screen lock available to you. I'm, I'm a bit cautious about the firefighter scenario. It should not be too many emergencies, rather the environment should have RO solid roles and the firefighter situation should really be an emergency and an exception.
Okay. Another question is, do you provide sod rule sets for the different industries or verticals?
No, that is something that we actually do not provide. We provide the technology. We provide the sod engine that is capable of evaluating, as I mentioned, authorization codes, fields values, and, and bring these in, in conflict. But the so D rules need to come from our customers. I actually prefer if we could get the actual rule set that the auditors of our customers are using to audit our customers so we can implement them in the system, which will make life easier for our customers as well, since the auditors are pro auditing against these rules or checking these rules, when we can make sure that we have implemented these rules and that we are actually checking against the same rules, it will make the life easier for our customers.
Is it possible to integrate with an existing SAP GRC solution?
Yes, absolutely. So it is very often the case that we come to a customer and the customer has already sub GRC access control in place. And also the, the roles, sorry, the rules they are, are in the system and, and active. So sub access control or sub is accessible through different web services. And we pretty much can integrate with these web services as much as the vendor itself does and ask sub GRC to actually do the sod check or even do the provisioning piece if, if necessary. However, when we integrate with sub GC and, and check the so D through sub JC, still all the restrictions apply, meaning sub GRC will look only on the account level and will not see that that identity probably has another account, or it will not find a violation for something that is outside of, of SAP.
Okay. Thank you. So we are at the end of the time that we have for today. So thank you for all that. It attended the webinar and we hope to have you soon in one of our upcoming events. Thank you, Jen Tuto for your presentation. And I hope everything was interesting to the audience. All right. Thank you. Thank
You very much.