25.02.2014 by Martin Kuppinger
When looking at the core IAM (Identity and Access Management) market with its main product categories of Identity Provisioning and Access Governance, some customers and vendors currently raise the question of whether there is still a need to keep these product categories separate or whether a single, combined view on these is the better choice.
Looking at the vendor landscape, some vendors such as CA Technologies or Beta Systems still have two distinct offerings. Others merged their product line from either Access Governance towards integrated Identity Provisioning, such as SailPoint did, or the other way, by adding more and more Access Governance features to Identity Provisioning products. Dell is a good example of that. Oracle, as another example, focuses on increasingly integrating its product portfolio into one suite. Aside from that, there are various vendors that, for instance, have strong Access Governance capabilities with some Identity Provisioning, but also the opportunity to still integrate well with existing Identity Provisioning solutions of other vendors. Examples for that strategy include RSA/Aveksa and CrossIdeas.
But that is only the vendor view on what is happening in the market. The more important question is: What serves the customer’s needs best? There is not a single right answer on that question.
It depends, perhaps, on where these customers are today. Customers that have already successfully deployed an Identity Provisioning solution might opt for a separate Access Governance tool for various reasons, such as reducing vendor lock-in or just because the Access Governance capabilities of their Identity Provisioning solution are not good enough. However, replacing an established Identity Provisioning tool might be too huge an effort to be considered economically feasible.
I also see many organizations, including large organizations, that want to proceed step by step and feel that they should first do the Identity Provisioning basics right. On the other hand, there are many organizations that need a rapid solution for Access Governance, without all the overhead that the technical elements of Identity Provisioning might cost.
There are various other scenarios I have described in detail in a report on Access Governance architectures. My perspective and experience is that there are varying customer requirements. While some need only Identity Provisioning (for instance to replace existing products, having Access Governance already deployed), while others need integrated solutions or only Access Governance (for rapid deployment or to integrate with existing provisioning tools).
Aside from the different customer requirements, there are pros and cons of integrated solutions. On the positive side there is that customers only need one tool and that the potential complex integration of Identity Provisioning and Access Governance is already done. On the other hand, there are scenarios where it is about integrating with existing Identity Provisioning tools. Aside from that, solutions that try to cover everything have a tendency to become more complex, while sometimes lacking the depth of features specialized solutions provide. Some vendors manage that well, while others are not as perfect.
Beyond that, there is another argument that speaks for keeping Access Governance and Identity Provisioning separate. While Access Governance focuses on business users and bridging the gap between business and IT, Identity Provisioning is far more a technical solution for interfacing with target systems. There might be different owners; there are definitely different user requirements.
These are just some of the reasons why we still keep these segments separate. We are currently updating our Leadership Compass on Identity Provisioning and will do so for the one on Access Governance. We are also working on a Leadership Compass on IAM Suites, looking at the overall IAM market well beyond Provisioning and Access Governance.
Importantly, in both our Identity Provisioning and our Access Governance Leadership Compass, we already evaluate the strength of Identity Provisioning products to support Access Governance requirements and vice versa. However, that is just one view that is kept separate, allowing customers to make their own decisions, depending on their requirements. Putting everything into one basket appears, from our perspective, to be inadequate for that complex market.
17.08.2011 by Martin Kuppinger
During the last years, there has been a lot of change in the Identity Provisioning market. Sun became part of Oracle, Novell is now NetIQ, BMC Control-SA is now at SailPoint, Völcker has been acquired by Quest, Siemens DirX ended up at Atos. These changes as well as other influencing factors like mergers & acquistions, failed projects, and so on lead to situations where customers start thinking about what to do next in IAM and around provisioning. Another factor is that sometimes provisioning solutions are implemented with focus on specific environments – SAP NetWeaver Identity Management for the SAP ecosystem, Microsoft FIM for the Active Directory world. Not that they only support this, but they might be just another provisioning system. In addition, especially in large organizations it is not uncommon that regional organizations start their own IAM projects. The result: There are many situations in which organizations think about what to do next in provisioning.
However, just moving from product A to product B is not the best approach. In most cases, the deployment of provisioning tools took quite a while. In many cases there have been lot of customizations been made. And even while there might be some uncertainty about the future of the one or other product (or, in some cases, the certainty that the product will be discontinued sometimes in the future), just migrating from one provisioning tool to another seems to be quite expensive for little added value.
From my perspective, it is important for organizations to move at their own pace. The approach to do that is to put a layer on top of provisioning systems. I’ve described several options in a research note (and some webinars) quite a while ago. The research note called “Access Governance Architectures” describes different approaches for layered architectures on top of provisioning products. I’ll write an update later this year but the current version illustrates the basic principle well. By adding a layer on top of provisioning, which might be Access Governance, a Portal/BPM layer, or IT Service Management (or a mix), organizations can deal with more than one provisioning tool. The architecture is more complex than just using one provisioning tool. But if you are not able to rely on one provisioning tool only, its at least an approach that works.
Organizations then can for example replace provisioning tools fully or partially. The latter is quite common if complex customizations have been made for selected target systems. Organizations can deal with multiple provisioning systems that “just appeared” for some reason - M+A, specific solutions for a specific part of the IT ecosystem, or whatever. And they can move forward more flexible than in a monolithic architecture. Yes, these approaches require some more architectural work at the beginning, but that pays off. It pays off by more flexible migrations, by avoiding migrations at all, by less “political” conflicts with some of the lobbies within IT. It even enables to change the integration layer without affecting the underlying provisioning systems. And for sure it allows to interface with target systems in a flexible way, not only using provisioning tools but service desks or other types of connectivity if required.
But, at the end, the most important thing is that it allows customers to move forward at their own pace. Thus, before you think about migrating away from your current provisioning tool, think about how you can save your investments and add value – by new functionality and by business-centric interfaces of Access Governance and the increased flexibility of your IAM environment.
10.08.2011 by Martin Kuppinger
Is there a mismatch between the reality in organizations and the implementations of at least several of the Identity Provisioning and Access Governance solutions when it comes to the representation of physical persons in IT? To me it appears that there is a mismatch.
The reality in all large organizations I know is that the real world is sort of 3-tiered:
- There is a physical person – let’s call him Mr. X
- Mr. X can act in very different contexts. You might call them roles or digital identities, however all of these terms are overloaded with meanings. I’ll give three examples for that. 1. Mr. X might be an employee of an insurance company and a freelance insurance broker for the insurance company at the same time. 2. Mr. X might be an employee of a bank and a customer. 3. Mr. X might be the managing director of both company ABC, Inc. and DEF, Inc., which both are owned by XYZ, Ltd where he is employed as well.
- In each of these contexts, Mr. X might have more than one account. If he acts as external freelance insurance broker or customer, that might only be one account. If he is the managing director of some corporations within a group, he might have different Active Directory accounts, different RACF accounts, different SAP accounts, and so on.
You might argue that these are exceptions. However, being a customer of the employing company isn’t an exception in many organizations. And, by the way: A good and valid model has to support not only a standard approach but the exceptions as well. With other words: There are few situations in which a real-world model isn’t 3-tiered.
And there are good reasons to model the systems according to that. If someone is a customer of a bank and an employee, there are very obvious SoD rules which apply to this. He shouldn’t give loans to himself. If someone is a freelance insurance broker and an employee of the insurance, the same is true. He shouldn’t manage the insurance contracts he is selling. If someone is a customer and and employee, it’s the same again. He shouldn’t give discounts, grant consumer loans, or just change the delivery queue.
However, several tools follow a 2-tiered approach. They know for example an “identity” and “accounts” or “users” which are associated with the identity. If someone has more than one such identity, the problems begin. In some cases, it is very easy to adopt the object model. In others, you have to find workarounds like mapping the unique IDs of these identities into the other identities, which then might require a lot of additional code and is error-prone.
From my perspective, supporting a 3-tiered model out-of-the-box, with
- Context, Identities,… (whatever term you prefer)
- Users (in specific systems), accounts,… (again – choose your term)
is mandatory to reflect the reality in organizations and to support the business requirements – especially when it comes to SoD policies. If you don’t need three tiers, it is easy to just use two of them. But if your tool supports only two tiers out-of-the-box, it might become a tough task to implement your real-world model. Looking at that point is, from my perspective, one of the most critical aspects when it comes to technology decisions.
23.04.2011 by Martin Kuppinger
There is a new initiative driven by Google, salesforce.com, and Ping Identity called SCIM (Simple Cloud Identity Management). It claims to overcome the shortcomings of SPML (Simple Provisioning Markup Language), a standard being around for some 10 years. SPML has the target of being a standard for provisioning information between systems. It is supported by most provisioning and access governance tools, but only few target systems. SAP probably is the most important supporter.
Google, salesforce.com, and others in the cloud don’t support SPML. Thus, provisioning to these systems requires using proprietary APIs, if available at all – Google and salesforce.com provide such APIs, but not every cloud provider does. To overcome this, work on SCIM has started.
The first question however is: Why not use SPML? The main reason might be that SPML is XML-based, not focusing on REST which appears to be the somewhat more efficient (and especially, more accepted) way to implement standards for the cloud. Another might be that SPML is moving forward very slowly, if moving at all. There are many defencencies in SPML, no doubt about that. These start with the limited support by non-IAM-vendors. There are technical limitations as well, including performance issues in large scale deployments and limitations regarding what could be provisioned via SPML.
Nevertheless, I’d like to ask two questions:
- Wouldn’t it be better to join forces of SPML and SCIM to build a SPML version 3.0 which supports REST as well?
- If working on a new or improved standard, wouldn’t it make sense to address all relevant use cases? SPML doesn’t today and SCIM is not likely to do, when looking at the information provided today.
The first aspect seems to be more sort of a political issue between different vendors. However, having two standards doesn’t help anyone at the end of the day.
That’s even more true if both standards are too lightweight and don’t cover all the companies need today. When looking at the little piece of SCIM specification published it looks like SCIM will only touch the surface of what is required. The use cases are focused on providing user information to cloud services. However, the topic isn’t identity management, it is identity and access management. The access or entitlement part is the big thing to solve. Dealing with different APIs of different cloud providers for identities is an issue, but it isn’t the biggest one – several vendors (federation, classical on-premise provisioning, cloud provisioning) have addressed this at least for the leading cloud providers.
But what about controlling who is allowed to do what in these services? How to manage entitlements, e.g. group membership, authorization rules, and other things? XACML is a standard which supports this, but again there is little to no support by cloud providers for XACML – like with SPML. Thus, when starting to define a new standard, it shouldn’t be a too simple one, which SCIM appears to be at that point of time. It has one which covers all relevant use cases of identity and access management. There is only limited value in providing user information to a cloud service but still having to enter the proprietary web administration interface (or using some proprietary APIs) to control access for that user, to define groups, roles, policies, and so on.
My conclusion: There should be open standards for identity and access management in the cloud. Building on proprietary services is about repeating errors made before. But a new standard shouldn’t be too limited from the beginning. That, by the way, is one of the reasons I see behind the very limited success of SPML: It was too limited. I remember a conversation with one of the leading people involved in SPML years back from now where I suggested looking at use cases like supporting client lifecycle management solutions, e.g. tools supporting (amongst other features) software deployments. There are vendors today in the client lifecycle management market building custom integrations to HR or provisioning tools today, but not based on SPML – because they have never heard about SPML and because SPML never looked at this use case.
There might be a good reason for an effort like SCIM. But just being a REST-based standard but not really thinking beyond what SPML supported won’t solve the real world problems. Thus I strongly recommend to rethink SCIM and to look at significantly extended use cases.
If someone likes to discuss this with me in person, best is to meet at at EIC in Munich, May 10th to 13th.
14.04.2011 by Martin Kuppinger
User Management in SAP environments has fundamentally changed over the course of the last 10 to 15 years. When centralizing user management became an increasing demand of SAP customers, SAP introduced CUA (Central User Administration) several years ago. However, CUA has some restrictions and many customers have chosen other options like provisioning tools from 3rd party vendors. Thus, SAP has decided to change the approach. SAP NetWeaver Identity Management no is the strategic recommendation of SAP for managing users across SAP systems. If blogged about that before here and here.
We have recently run a survey on what SAP customers are doing today and plan to do. The range of SAP systems in production is pretty big, from several respondents using 4 to 10 instances, but a few having a farge bigger number in use, up to 200. Amongst the responding organizations, close to a quarter is using CUA today for all production instances, while another third is using CUA for some of the production instances. That might be based on the fact that CUA doesn’t support all SAP systems. The reason might be also that CUA hasn’t deployed as the strategic tool for user management in the SAP environment, covering all instances.
Most of the organizations started using CUA early, but some few deployed the tool after 2007 and thus after the first strategic announcements of SAP that SAP NetWeaver Identity Management will be the successor for CUA. However, most customers will migrate from CUA. Roundabout 60% plan to migrate to SAP NetWeaver Identity Management, but only one out of ten companies plans to move to provisioning tool of another vendor. Interestingly, some 30% of the organizations don’t plan to replace CUA within the foreseeable time. From the ones migrating roughly half have started their migration, while most of the others will make that move within the next two years.
The numbers prove that SAP appears to be successful with their strategy of migrating from CUA to SAP NetWeaver Identity Management. The customers tend to choose SAP NetWeaver Identity Management for user management within their SAP environments. Given that there are sufficient architectural options for IAM today, with Access Governance solutions or Service Request portals on top of one or multiple provisioning tools below that, this approach still leaves sufficient strategic options for the holistic view on IAM and Access Governance for the entire, heterogeneous IT environment.
To learn more about these options and how to best manage SAP and other environments from the user management, access management, and IT governance perspective, visit EIC 2011 in Munich, May 10th to 13th.
03.03.2011 by Martin Kuppinger
One of the discussion which pops up in many advisories is around the terms and related object to use in Identity and Access Management. This is directly related to the question which attributes to use where and which to import from HR.
My best bet and experience is that customers should look at three levels ob objects:
- Persons, e.g. the human being
- Identities, e.g. a virtual representation. There might be several identities for one person. Someone might be the manager of several companies within an organization. Or someone is working as an internal in an insurance and as external sales person. Or someone is a customer and an employee.
- Users or accounts, e.g. the representation in specific systems. There might be one or many accounts associated to an identity.
I didn’t cover service accounts and other things here – service accounts usually are associated with an identity which is responsible for that account. Thus it fits well into this list. Thus, technical users fit in there as well.
If you like that model, you should be somewhat careful when looking at vendor implementations. Many vendors have an oversymplified model which doesn’t support the person out-of-the-box. That could lead to some complex customization requirements and more complex provisioning tasks to keep person-related attributes in sync which then have to be stored per identity.
Now let’s look at the attributes:
- Some of them are associated with the person – the ones which don’t change per identity, like name, surname, date of birth, or sex. And a unique identifier.
- Some of them are associated with the identity, like the office location, the eMail address (most likely – there might be a primary eMail address defined for the person). And an identity-specific identifier which could change, like an employee number per company.
- Finally there will be few attributes per account, which are specific to the systems.
Which attributes to pick:
- Identifying ones – how can you clearly identify someone?
- Describing ones – what do you need for the yellow pages?
- Authorization focused ones – which do influence authorization decision, e.g. are in fact sort of “entitlements”?
Sounds easy – and, honestly: It is easy if you follow the best practices.
17.02.2011 by Martin Kuppinger
These days I’ve met with some of the executives of SAP to talk about their roadmap. Overall, SAP is moving forward with its Identity and Access Management products. e.g. SAP NetWeaver Identity Management (NW IDM). And the integration of the recently acquired SECUDE products and technology will significantly enhance the SAP product portfolio. Some of the new features are improved role management capabilities, reporting via SAP BW (Business Warehouse), and new REST-based APIs for UI creation. No rocket science, but valuable add-ons for their customers. For sure SAP is as well enhancing the integration with their core products and with SAP BO GRC AC (SAP BusinessObjects GRC Access Control).
The most interesting step forward, from my perspective, is the strong focus on SAML 2.0 which shall become the strategic replacement of SAP Logon Tickets, which are some form of proprietary cookies. This allows cross-domain use, in contrast to domain-dependent SAP Logon tickets. And it will provide simpler integration in business processes which span not only the SAP environment but heterogeneous applications. Besides the increased flexibility, SAML can provide much more information about the user. However the step from SAP Logon Tickets to SAML 2.0 won’t be a hard or even quick migration. SAP will further support the SAP Logon Tickets – and SAML 2.0 is supported only in backend systems starting with the 7.0.0 release. However, SAML 2.0 offers significant features and SAP provides (besides the integrated IdP in SAP NW IdM 7.1 and higher) as well SP capabilities at the backend.
Another area of migration is about moving from CUA (Central User Administration) to SAP NW IdM. SAP strongly recommends to use SAP NW IdM instead of the limited CUA capabilities. Again, this is a smooth migration – CUA won’t, according to SAP, be shut down as long as ABAP-based systems (the older SAP systems) are around. However it isn’t recommended anymore to install CUA.
In essence, SAP is continuously enhancing the Identity and Access Management capabilities and strengthens not only the integration into the SAP environment but adds support for heterogeneous environments and standards. Thus, SAP NW IdM is, from a SAP perspective, an enabling technology for the integration within the SAP infrastructure and (especially with SAML 2.0) beyond.
10.02.2011 by Martin Kuppinger
Being involved in a lot of advisory projects at end user organizations for some years now, I’d like to share some of the fundamental changes I observe. There is always a gap between what analysts like us, KuppingerCole, predict and what is done in reality. Thus it is always great to observe that things we’ve predicted and proposed are becoming reality. So what has changed over the course of the last years – trends becoming reality:
- Access and Identity Management: Back in 2008, I’ve blogged about the relation of the terms “access” and “identity”, the latter being much more difficult to explain. Today, the clear focus is on access controls, they are in focus.
- More flexible architectures: Some time ago, the idea was to have one provisioning system which covers all. Today more flexible architectures like described in one of my research notes become reality. Access Governance on top of several provisioning system allowing to protect existing investments and to move forward in smaller steps are increasingly common – and the increased maturity of Access Governance tools is the foundation to do this. Provisioning is increasingly seen as a technology layer below such integration layers (not necessarily Access Governance). And so on…
- Access Governance on top, doing things more business centric: A consequence of this is that companies focus much more on the business user and their requests for access (yes, for access, not mainly for identities). This isn’t entirely new but the way IT interacts with business has changed over time.
- Integration with service request approaches (not service desk, like BMC believes): Another tendency is to integrate access and identity requests with other service requests, either in the IAM/Access Governance tools (like in Quest One ActiveEntry or through Avatier AIMS, to name just two) or in service catalogs. However the interface has to be fore business users, not the IT – e.g. not the service desk itself. Service desks are as well increasingly part of the integration, within the more distributed architectures mentioned above, but for the manual part of fulfillment in systems which aren’t connected through a provisioning system.
- Bodies of rules, policies,…: The, from my perspective, most important change is that more and more projects start with the definition of “bodies of rules”, policies, concepts – and not with the selection of a technology. That definitely makes sense: You don’t start building a house by buying stones, you start with blueprints.
Two more (amongst others) trends increasingly becoming reality are
- Externalization of security out of applications in a standardized way, based on XACML and other approaches (and yes, there are real world projects out there on this)
- Hybrid cloud IAM and Access Governance – how to deal with mixed environments
Overall there is a clear shift of how IAM is done. And this change will continue, with the upcoming integration of Access Governance and other IT GRC approaches into enterprise-wide GRC concepts.
To learn more about the trends as well as the best practices don’t miss EIC 2011, where thought leadership and best practices come together.
12.08.2010 by Martin Kuppinger
Provisioning is important to keep access under control, as well as Access Governance solutions play a vital role in that game. However, there is a third group of applications which is commonly required: Tools which allow to dive into the details of access controls in specific environments. There are SAP specific solutions and tools for mainframe environments, XACML for standardized entitlement management for custom applications might be counted as well – and there are tools for the world of less structured information, like file servers, Microsoft SharePoint, and others.
These tools are important to enable a detailed analysis of access rights at the level of files, folders, and shares – when looking at file servers. Provisioning helps us to ensure that a user has an Active Directory account and is member of some specific groups. But what are these groups allowed to do – in detail? Some Access Governance solutions might provide some details, but typically not as specific as the expert tools in that area can do. And there are many tools out there. These days I spoke with Protected Networks, but Econet, Tesis, and ASB - to mention just some German vendors – can deliver on this as well, with somewhat different approaches and capabilities. And these are just some examples.
From my perspective, we need a layered approach – Enterprise GRC, Access Governance, Provisioning, and the specific tools for different important application environments. And we need to integrate these tools. That will enable organizations to fulfill the governance needs and compliance regulations at all levels – with an integrated approach and avoiding investing in point solutions.
By the way: If you as a vendor feel that you fall in that category (for AD and file servers, for SharePoint, for SAP), just keep us informed. We might have you on our watchlist but given that this is a market with many smaller vendors in, we might have missed you until now…
06.08.2010 by Martin Kuppinger
SAP recently has announced that their SAP NetWeaver Identity Management 7.1 now includes an SAML 2.0 Identity Provider – it requires the Service Pack (or Support Pack) Stack 5 (by the way: who at SAP is responsible for product names??? SAP BusinessObjects GRC Access Control; SAP NetWeaver Identity Management 7.1 SP Stack 5;…).
SAP is commited to SAML (Security Assertion Markup Language) for a while now – and SAML 2.0 support is found at many places in the SAP portfolio. SAP systems can act as service providers in federation scenarios, with SAML 2.0 enabling the Single Sign-On and sharing of identity-related information. Using the identity provider within SAP NW IDM 7.1 SP 5 (to keep the name short and make it even more cryptic) allows to use a centralized view on identities within federation. The product can provide the unified view on identities which is a foundation for federation. Without identity information quality, there is no successful federation: Garbage in, garbage out.
The enhancement of the product shows where SAP is heading: It is a central element within the SAP NW infrastructure which provides all the identity services required in that infrastructure. There is tight integration with SAP products, but as well support for standards to integrate external applications – like with SAML 2.0 and the inherent support for Non-SAP service providers as well.
The other important enhancement in SP 5 are the Identity Reporting Capabilities based on SAP NetWeaver Business Warehouse. That enhances the reporting capabilities of SAP NW IDM 7.1 – but it requires to have the Business Warehouse product in place. Anyhow, the enhancements clearly demonstrate the strategy of SAP for NetWeaver Identity Management: A central piece in the SAP infrastructure, well integrated, and with standards support. The enhancements demonstrate another point: SAP is executing on its strategy consequently. Maybe a little too quiet, but they are moving forward.