01.07.2014 by Martin Kuppinger
Most organizations have a Microsoft Active Directory in place. The Active Directory (or, in short, AD) builds the foundation of their on-premises infrastructure for managing users, performing their primary network authentication and authentication to AD-integrated applications such as Microsoft Exchange Server, and some network infrastructure services including client configuration management based on Group Policies. AD is a purpose-built directory service that is optimized for supporting these requirements. One of the specific capabilities are Group Policies – client management commonly is out-of-scope of directory services. Another example are the sophisticated replication features of AD. These are required to provide (amongst others) seamless authentication and load-balancing of authentication requests and user management.
This works well for the employees and the on-premise IT infrastructure. However, when it comes to external users, things becoming more challenging. While most organizations manage the “long term” externals – the ones who spend a lot of time on-premises, need access to internal IT systems and frequently even have a company e-mail address – in the Active Directory, organizations struggle with managing all the other externals such as employees of business partners with occasional access only to a selected application or customers.
The purpose-built AD is not targeted towards these use cases. On-boarding and off-boarding thousands of employees of an insurance broker or managing the local operators of an airline across the world are not the standard use cases for AD. And what about managing millions of customers that need access to some applications?
There are workarounds, but none of these workarounds is really convincing. These external users might be managed in a separate forest or in a separate domain within an existing forest. They might even be managed within an existing domain (particularly in ADs that follow a single-domain approach), but that makes security management pretty cumbersome. And we do not yet speak about some challenges such as schema changes for specific requirements or the replication issues caused by managing a multitude of users than just the employees in the Active Directory.
The common answer on these challenges is to set up another, separate directory service for external users or customers. Microsoft’s lightweight answer is AD LDS (Active Directory Lightweight Directory Services). Other vendors provide their LDAP (Lightweight Directory Access Protocol) directory servers to manage these users and authenticate them.
But there is another answer now: cloud-based User and Access Management as part of the emerging cloud IAM offerings. Several vendors deliver solutions that allow managing customers and external users in integration with the existing on-premise infrastructure. Microsoft’s own answer in that field is the Azure Active Directory, a cloud-based directory service that it is quite different from the traditional Active Directory. It supports flexible schemas, scales virtually unlimited (Microsoft Office 365 is based on it), and provides functionality that helps managing external users far better than the on-premise Active Directory can do – and potentially better than other on-premise directory services can do. With upcoming extensions, Microsoft will further add capabilities for managing external users.
There are challenges such as synchronizing and/or federating the existing users of AD and other directory services to Azure Active Directory (or other services in that field).
Nevertheless, there are new options now to extend the existing AD to the cloud and to serve new business demand of on-boarding, off-boarding, and managing business partners and customers – delivered by Microsoft and other players in the market. This creates a situation for organizations using AD in which they should start reviewing and rethinking their Active Directory strategy. There are various options for extending the on-premise AD to the cloud, and it is time for defining the future strategy around AD. That future, for most organizations, will be hybrid.
This article was originally published in the KuppingerCole Analysts’ View Newsletter.
30.09.2013 by Martin Kuppinger
In Azure Active Directory (AAD) there is a Graph API. This is the main API to access AAD. The idea of a Graph API is not entirely new. The one provided by Facebook is already well established. But what is this really about and why does AAD provide such an API?
First of all, I neither like the term “Graph API” nor “API” itself very much. Both are, from my perspective, far too technical. They are fine for people with a good background in mathematics and computer science, but not for typical business people. A graph is a mathematical concept describing nodes and their connections. The structure of AAD can be understood as a graph. To navigate this graph, there is an API (Application Programming Interface) – the Graph API.
So the AAD Graph API is the interface for navigating the content of AAD (walking the tree, or, more correctly, the graph) and accessing (and creating and manipulating) the information stored therein. Developers can perform CRUD (Create, Read, Update, Delete) operations through REST (Representational State Transfer) API endpoints when developing applications such as web applications and mobile apps – as well as more conventional business processes.
It comes as no surprise then that the Graph API is REST-based. REST is the de facto standard for new types of APIs. It is rather simple to use, especially when compared with traditional methods for directory access such as the LDAP C API (yes, it always depends on what you compare something with…).
The Graph API of Azure AD provides a broad set of standard queries that can be used to retrieve metadata information about the tenant’s directory and its data structure, but also about users, groups, and other common entities. Apart from these standard queries, there are so-called differential queries that allow developers to request only the changes that have happened on the result set of the query since the previous query run. This is very interesting for applications that need to synchronize AAD and other data stores.
Access to the Graph API is done in two steps. The first one is the authentication (based on tenant-ID, client-ID and credentials), which is done against the Windows AAD authentication service. The authentication service returns a JWT Token. This token then can be used for running Graph API queries. The Graph API relies on an RBAC (Role Based Access Control) model. It authorizes every request and returns the result set if the authorization has been successful.
Overall, the Graph API is a simple yet powerful concept for accessing content of the AAD. It is the successor to traditional approaches for directory access such as LDAP with its rather complex structure (which is simplified by ADSI, ADO .NET, etc.). Being based on REST, it is a familiar approach for web developers. There is a lot of information already available at the MSDN (Microsoft Developer Network) website.
From the perspective of a non-developer, the most important thing to understand is that it is far easier than ever before to build applications that rely on the AD – or, more particularly, on the AAD. All the information about the employees, business partners, and customers that organizations may hold in the AAD in future is accessible through the Graph API for new types of applications, from integration of that information into business processes to simple mobile apps providing, for instance, customer information out of the AAD. This is done in a secure way, based on the built-in security concepts of AAD such as the RBAC model. Graph API is one of the things that moves AAD from a purpose-built Directory Service (such as the on-premise AD) to a platform that allows you to flexibly connect your enterprise – the users, the things, the applications.
23.09.2013 by Martin Kuppinger
Some time ago Microsoft unveiled its Azure Active Directory (AAD). During recent weeks, I have had several discussions about what AAD is. First of all: It is not just an on-premise AD ported to Azure and run as a Cloud service. Despite relying in its inner areas on proven AD technology, it differs greatly from on-premise AD. It is a new concept, going well beyond a classical directory service and integrating support for Identity Federation and Cloud Access/Authorization Management.
In fact you can use three flavors of AD today:
- The classical on-premise AD
- The on-premise AD running on Azure in virtual servers
- The AAD
The second variant is rather unknown but might be interesting in some use cases, when organizations want to optimize their existing on-premise AD infrastructure.
However, the most interesting element in this family of ADs clearly is AAD. AAD is a new type of thing that is“more than a directory service”. It can integrate with existing AD infrastructures, best by using Identity Federation based on ADFS (Active Directory Federation Services) and SAML v2 as a protocol.
It then is a service that runs as a real Cloud service:
The latter aspect is proven and looking at it provides some additional insight into AAD. AAD was out long before it became publically available. It is the directory service in use by both Microsoft Office 365 and Microsoft InTune.
When looking at existing AD infrastructures, there are some common challenges that AAD can address, aside from running as a Cloud service (there you also could use the on-premise AD running on Azure).
One of the common challenges for AD are schema changes. Schema changes are a nightmare for many administrators. They can’t be rolled back. And they might affect the AD performance. Thus, many administrators are extremely reluctant to make any schema changes. AAD solves this with its flexible, extensible data model. This data model has left the LDAP/X.500 history that still is visible in AD. Thus it comes to no surprise that the primary means of access to AAD is not via LDAP (which is not even supported out-of-the-box yet) but through the REST-based Graph API.
The second common challenge AD administrators are facing (amongst some others…) is the management of external users. Many organizations have implemented some approach to managing such externals, for instance in separate domains or at least subtrees. However, these approaches are not easy to define and implement from both a security and a scalability perspective. It might work rather well for some business partners and sub-contractors that need access for a longer period of time. However, onboarding thousands of employees of new business partners (for instance for sales to new target groups or in new regions) is something the on-premise AD is not ideally suited for.
AAD is built for that. It not only can scale flexibly – think about millions of customers instead of some thousand or tens of thousands employees or business partners – but it also supports federation by design. It can federate both inward and outward. In other words (and as mentioned above): It is not only a directory service but a federation platform.
And even more: It also is a tool that you can use to manage access to other Cloud Services. It can act as authorization services for these, when federating with them. Based on policies, access to such services can be managed and restricted.
So there is a lot more in AAD than in the on-premise AD. AAD is the logical extension of AD for the “Extended Enterprise” or “Connected Enterprise” – whichever term you chose. It allows managing external users far more simply while being massively scalable. It allows managing access to Cloud services. And it still behaves well in conjunction with existing on-premise AD environments.
There are alternatives to AAD in the market. However, AAD is one of the Identity Cloud services worth having a deeper look at. The most important thing you should do when looking at AAD is to accept and understand that this is far more than the on-premise AD ported to the Cloud.
I will cover some aspects of AAD and the surrounding (and growing) ecosystem in upcoming blog posts.
22.06.2011 by Martin Kuppinger
Do you remember Calendra? The vendor which was acquired by BMC many years ago? At least many existing and remaining customers require Calendra. And some of them really miss the company.
What made Calendra popular was their tool which allowed to quickly building applications to deal with information held in directories. That approach was different to provisioning, different to meta directories, and it was not just hard coding everything. Being a specialized IDE for database environment, it allows customer to quickly build directory-based applications for example to manage employee data or to implement specific approaches for delegated administrators.
Even while some few vendors try to fill the gap, there appears still to be sort of such a gap. But there is more than a silver stream at the horizon. The German company ITConcepts, a BMC partner (amongst others), has acquired the Calendra technology and is re-launching it. The product will be named Cognitum. The first version, available now, is more or less a rebranded version of the existing Calendra product. ITConcepts plans to quickly release an updated version with support for newer versions of Java stacks and some other maintenance, before moving forward with functional enhancements.
The good news for existing Calendra customers today is: Someone is working actively on that product again and provides support. And ITConcepts has a defined roadmap which looks realistic and doesn’t promise too much. However, given that ITConcepts has been a system integrator only until now, it will be interesting to observe how they execute in the software business. In any case, it is worth for Calendra customers to have a look at this offer. And chances are good that the gap in the overall IAM landscape which has been sort of left when Calendra was acquired by BMC will be filled again.
09.07.2010 by Martin Kuppinger
It became pretty quiet around directory services during the last years. When I remember the discussions back some 10, 15 or 20 years around NDS versus LAN Manager (and the underlying domain approach) or Active Directory when it came to market, and even the discussions which came up in the early days of OpenLDAP, it is pretty quiet nowadays. Are all the problems solved? Are the right directories in place? Are the best solutions chosen when something changes?
When talking with end user organizations it becomes obvious that we are far away from that state. There are implementations of different directories, and most of them work well for their specific use case. But once it comes to optimization, the situation changes. What to put in the Active Directory, what not? How to optimize the way applications are dealing with directories? How to best build a corporate directory or a meta directory (the directory as data store, not the meta directory service as technology for synchronization!)? How to interface directories for specific use cases and how to best retrieve information?
There are many aspects to discuss and to understand to end up with an optimized “directory infrastructure”. First of all, it is important to understand which directories you have and how they are used – usually there are far more directories out there than you’d expect. And I’m not only talking about the Active Directory, eDirectory and all the LDAP servers, but as well about “de facto” directories in the form of tables in databases and so on. I’m talking about anything which acts as a directory. That includes the application directories, which might be hundreds of small directories. And they sometimes contain sensitive information like privacy-relevant data. Besides this, they frequently have somewhat redundant data. Based on this analysis, you can drill down and identify which attributes have to flow between which directories in which use cases.
The latter is more about really optimizing your provisioning. The analysis is, on the other hand, as well a good foundation for optimizing your directory infrastructure. Where can you avoid redundancy?
Based on such an overview, you can think about some other aspects:
- Which central directories do you need for which use cases?
- How to optimize application access on directories?
- Where do you need specific technology for these directories beyond standard LDAP?
There is always a need for some more or less central directories. The Active Directory or eDirectory are examples, used for the primary authentication of internal users and for many infrastructure services – but they can’t do anything. There are Corporate Directories for centralized access to corporate information. There are more technical meta directories as the “source of truth” about distributed information.
We have to think about optimizing the application directories. One or few centralized directories together with Virtual Directory Services which are offered for example by Radiant Logic, Oracle, and Symlabs are an interesting option do build such a centralized yet flexible infrastructure, with the Virtual Directory Service as interface layer.
And we have to look at specific use cases where we need specialized technology. There are some innovative vendors out there. UnboundID for high scalable environments, where others like Oracle, Novell, Siemens, and so on are active as well. eNitiatives with their ViewDS services for strong querying capabilities and the ability to easily build interfaces in a “yellow page” style to these directories.
My experience is, that there is still a lot of need to think about directory services – and there is a lot room for improvement in most IT environments. What is your view on that topic?
20.06.2010 by Martin Kuppinger
LDAP (Lightweight Directory Access Protocol) is well established. It is the foundation for today’s Directory Services, which support LDAP as a protocol and which usually build their data structure on the associated LDAP schema. There are many interfaces for developers to use LDAP, from the LDAP C API to high-level interfaces for many programming environments.
Even while LDAP is well established, it is somewhat limited. There are several restrictions – two important ones are:
- The structure of LDAP is (more or less) hierarchical. There is one basic structure for containers – and linking leaf objects (think about the association of users and groups) is somewhat limited. That structure is a heritage of X.500, from which LDAP is derived – with LDAP originally being the lightweight version of the DAP (Directory Access Protocol) protocol. X.500 was constructed by telcos for telcos, e.g. with respect to their specific needs of structuring information. However anyone who ever has thought about structuring Novell’s eDirectory or Microsoft’s Active Directory knows that there is frequently more than one hierarchy, for example the location and the organizational structure. The strict hierarchy of LDAP is an inhibitor for several use cases.
- LDAP is still focused on the specific, single directory. It doesn’t address the need of storing parts of the information in fundamentally different stores. But the same piece of information might be found locally on a notebook, in a network directory like Active Directory, in a corporate directory and so on. How to deal with that? How to use the same information across multiple systems, exchange it, associate usage policies, and so on? That is out-of-scope for LDAP.
I could extend the list – but it is not about the limitations of LDAP. LDAP has done a great job for years but there is obviously the need to do the next big step. An interesting foundation for that next big step comes from Kim Cameron, Chief Identity Architect at Microsoft. He has developed a schema which he calls system.identity. There hasn’t been much noise around before. There is a stream from last years Microsoft PDC, there is little information at the MSDN plus a blog post, there is the Keynote from this year’s European Identity Conference. But it is worth to have a look at that. The approach of system.identity is to define a flexible schema for identity-related information which can cover everything – from local devices to enterprise- and internet-style directories, from internal users to customers and device identities, including all the policies. It is, from my perspective, a very good start for the evolution (compatibility to LDAP is covered) well beyond LDAP and today’s directories.
I’ve put the concept under a stress test in a customer workshop these days. The customer is thinking about a corporate directory. Most people there are not directory guys, but enterprise IT architects. And they definitely liked the path system.identity is showing. It covers their needs much better than the LDAP schema. That proved to me that system.identity is not only for the geeks like me but obviously for the real world. Thus: Have a look at it and start thinking beyond LDAP. The concept of system.identity, despite being early stage, is a very good place to start.
09.02.2009 by Martin Kuppinger
Last week I’ve been talking with Andrew Ferguson and Steven Legg of eB2Bcom. Probably you’ve never heard of them, at least as long as you are neither from the APAC region nor working in the government and defense business where they have most of their customers outside the APAC region. eB2Bcom is, first of all, a system integrator and distributor of IAM and GRC products.
But eB2Bcom is as well the company which develops the View500 directory service. You haven’t heard of this product? At least it is worth to have a look at. Basically, it is a directory service which goes beyond typical directory service offerings, which mainly focus on being the best LDAP server. They have for example integrated XML support, for SAML, XACML, or ebXML. Thus, they go well beyond the DSML support some directory services are offering – with DSML being in fact sort of a web service incarnation of LDAP. The difference is that the semantics of XML documents are supported. Other features include the matching of synonyms or typing correction for improved search and indexing.
eB2Bcom ist adding additional features. The support for SAML and XACML is particularly interesting. In adding these capabilities to the directory service, that system can for example act as an integrated identity provider for federation. Instead of having a federation system and a directory server, it is one system with obviously less communication overhead. The same is true with XACML support and the directory acting as PEP (Policy Enforcement Point). One system instead of two or three in typical implementations.
Interestingly, what Microsoft is doing around Active Directory with ADFS (Active Directory Federation Services) or the server components of “Geneva” isn’t that different. It is sort of “pimp my directory server” by directly adding additional features instead of delivering separate products. The closer to the directory these features are implemented, the more efficient they are. On the other hand, we might end with well integrated solutions which lack important features. Thus this approach isn’t a no-brainer, for sure. But I think it is really worth to consider if there aren’t features which are best integrated with directory services because the directory service is, anyhow, asked all the time. Thus, instead of having the directory service providing just a part of the answer and another system adding to that answer (with repeated requests to the directory server, complex caching,…) it might be a good idea to do all these things in one place.
That won’t solve everything – but it is an interesting option. By the way it might as well be a good choice to add some virtual directory service capabilities to a directory server like Sun has done this with their Sun Directory Server instead of fully relying on an external virtual directory service. Might also provide a better performance especially in the situations in which most of the requested data is in that directory.
Another interesting point is that XML-enabled directory service will become an interesting option for a centralized policy management. They can store these policies and provide them or answer requests about these policies. Another emerging field where that approach might become popular over the next few years.
I will have a look at the evolution in the directory services market. And, from a vendor perspective, it is worth considering these options because it would move directory services back from a commodity to a market segment where companies can earn a lot of money because they have strong unique selling proposition due to the services they’ve added to their directory service.