Hello, and welcome. My name is Hanno Bunjes. And I'm happy to be with you all today. Thank you for joining this session on application governance with Identity Manager.
So the main question that we're trying to answer today is how does Identity Manager help you prove that your applications are under governance. Central to application governance is the persona of an application owner. So application owners are the ones who manage applications who know exactly which entitlements and roles application consists of.
So once business applications are defined, owners can then manage how access to these applications can be requested in the IT shop of Identity Manager. Key performance indicators help validate compliance against business objectives. Application governance contains a set of predefined KPIs to track compliance over time. Governance-relevant information can be defined based on these business applications. So once you have established applications as a concept, you can leverage this information when defining, for example, SOD rules or, for example, saying that no one should have access to two critical business applications at the same time.
The next release of Identity Manager will include this new application governance module that bring applications to the data model as a first class citizen. Let me take a moment to clarify some things that application governance is not. For example, it's not about connectors or mapping fields.
Data import from external systems happens before you define business applications. Application governance does not care how exactly entitlement data is important to the system. It's also not something low level or technical.
It's not something that is reserved for IT or operations teams. It's very much something that is involving the business team members who are the subject matter experts for business applications. Also, it's worth pointing out that application governance is an optional new module, and it does not change how the various Identity Manager components interact with one another.
Application governance works on top of everything else. It's not an architectural change. It adds functionality to the IT shop. It adds functionality to [INAUDIBLE] station and to other modules, but it does not replace any of those components.
So what is an application? A business application simply is comprised of a set of entitlements. If you import data, entitlements often exist as a simple flat list, and bringing these entitlements under governance is mostly about organizing them into larger and more manageable units-- the applications. For example, when an entity has customers who use AD LDS tree to implement thousands or [? 10,000s ?] of business application authorizations, a business application may not exist as such in any one target system. It may span several types of target systems.
What is an entitlement? It can be anything from the Identity Manager data model that you would expect. It could be a system entitlement from the unified namespace, which is our abstraction of all possible target systems. It could be a system role which itself bundles entitlements. Resources or account definitions as well as report authorizations can also be added as entitlements to applications.
It's worth saying that of course you can mix entitlements from different types into one application. Let's take a look at creating an application. This is the simple web form that the administrator uses to create a new application in the system. The interface prompts for just a few properties that are central to the definition of an application. There are actually lots more.
You have the option to create a new service category or to reuse an existing one. This integrates well with a situation where you may already have configured entitlements and service categories, and you're just now moving to define applications. Once you've added the application to the system, you can add new entitlements or roles at any time.
Here you have the option of publishing entitlements to the IT shop one or several at a time. Unpublishing is the opposite-- removing the entitlement from the shop and revoking user's access. Here's what happens when I click Publish.
I see the list of IT shops that the entitlements will be published in. IT shops define the scope of service items visible for a given user. You can have different shops to define different catalogs for groups of users-- for example, if you want to organize the shops by region or by department, for example.
It's easy to schedule a date in the future when the entitlements should be added to the shop. You can set up a publishing date now so that users will be able to request access starting next month, for example, and once you've told the system to publish the new entitlement, not the new state. Let's take a closer look at publishing entitlements.
[? Now ?] some of you are very familiar with the internal architecture of identity manager, and you may have been wondering-- what about service items? Well, the good news is when an entitlement is published, a service item is created if necessary. So you don't need to do that manually.
The entitlement will become available through the assigned IT shops and the selected service category. These use cases are all available in the web UI. There is no need to deploy a .NET front end like the manager tool to do this.
Here's another cool feature that we built-- the on-the-fly role creation. When adding entitlements to the application, you also have the option of grouping related entitlements in a role. Why should you do this?
Well, this is useful in a scenario where different entitlements should only be requested as a bundle and not individually. This is a long requested feature for all of Identity Manager, and we're now able to bring this feature to the product. But there's more to the application.
This is all information that the application owner can enter. Does the application run in a test environment, in staging, or in production? What kind of authentication does the application implement-- single