Identity Management in Retail and Hospitality
Microsoft Identity Integration Server 2003
Microsoft Active Directory
Summary: This article introduces automated identity management (IDm) through solutions such as Microsoft Identity Integration Server (MIIS). It focuses on how these solutions can address the needs of the Retail and Hospitality industries in particular. (14 printed pages)
What Is Identity Management?
ID Trends and Issues
Retail and Hospitality Challenges
Identity Management Scenarios
How MIIS works
Single Sign-On (SSO)
Retail and Hospitality are two of the most cost-conscious industry sectors. They work on thin margins and long technology refresh periods. The manual management of user accounts and other resources in the intranet and extranet can be a significant operational cost to organizations. Identity management (IDm) solutions can automate management in the following ways:
- Accelerating the provisioning and deprovisioning processes.
- Ensuring that security policies and permissions are appropriately applied, enforced, and audited.
- Resolving and maintaining data integrity.
- Reducing the overall cost of operations.
Before talking about IDm, we should probably talk about what constitutes an identity, and how it is stored. Typically, we think of identities as being users or employees; however, in the wider context, an identity represents a unique object, which may be a user, but it can also be a printer, security principal, server, or a service—basically any resource that is present in our organizations or in our extended organizations, such as trusted partners. An identity can cross multiple systems, and it does not necessarily constitute an electronic or digital identity. It can also apply to paper or other mediums.
A directory is a collection of identities. Not so long ago, if someone talked about a directory, we would think of the corporate directory, a phonebook, or the Yellow Pages. Today we think of Active Directory directory services (AD), LDAP, and other electronic directories. When we look at a typical enterprise, it is not unusual to see over 100 directories in use, ranging from the printed office phone list, to the HR system, badge/security system, PBX, or VoIP, to AD and other LDAP-enabled directories. Each of these systems contain information about the resources in the organization, but many are maintained (or not) by different groups within the enterprise. In many cases, these systems are manually maintained.
Herein lies a problem—legacy systems have evolved, data is aging, humans make mistakes in data entry, and data that should be consistent across all of the directories has diverged as a result. Systems may not have been updated, or if they have, new errors could have been introduced. All instances of a data element may not get updated, because the different systems have different formatting standards; as a result, jDoe, John_Doe, and Emp#5678 don't get reconciled, even though they refer to the same resource. In addition to being error-prone, manual management of multiple systems is time-consuming and costly. Analysts estimate that a password reset for a typical user across multiple systems costs around $40, and a change to the attributes of a resource would be significantly more. So, hypothetically, in a company of ten thousand employees, if a typical user forgets his or her password four times each year and requests a reset, password resets cost the business $1.6M per annum.
In an ideal environment, there would be a single, consolidated directory. All systems and users would leverage that directory, in place of the printed corporate list, for network and application authentication and authorization, and for address and phone number lookup. The PBX or Call Manager would connect to it for call routing, and e-mail, Instant Messaging/Real Time Collaboration, and calendars would all integrate using the common directory. Although this is perfectly feasible given a large enough IT budget or a green-field opportunity, the reality is that almost all environments will contain multiple systems leveraging multiple directories from AD and SQL to flat files and mainframe directories such as Resource Access Control Facility (RACF).
So, in a multiple-directory environment, how can we provide a single, consolidated identity, ensuring that data integrity is maintained? How can we guarantee that changes to an identity in one directory are realized across all directories in a timely manner? The answer is an IDm solution. What this provides is a single point of management for directory objects with automated provisioning/deprovisioning, distribution of updates (deltas only, where supported), password resets, and the brokering of conflicting updates.
According to research published by Forester Research in December 2004, many issues and trends influence the IDm solution space (see Figure 1).
Figure 1. Cyclical nature of Identity Management
The Health Insurance Portability and Accountability Act (HIPAA) was one of the first compliance drivers for IT. Subsequent accounting scandals and large-scale fraud have rocked the business world over the last decade, leading to the collapse of some of the largest companies in the United States. These scandals have severely dented consumer and stock market confidence. Sarbanes-Oxley (SOX) is a regulatory compliance directive that ensures that there is a level of accountability within an organization, to reduce the risk of fraud. The SEC has also introduced compliance directives to the same end. The implication is that there should be individual accountability for transactions in the enterprise. Users' identities must be unique, and their actions must be auditable. This requires the ability to ensure that users only have appropriate permissions to resources, and that auditors can take a point-in-time snapshot of which users had access to which data at a given time, and which of them updated that data. Linked to this is the need to ensure that the user who is logged in is who he or she claims to be. In many cases, this requires the strengthening of passwords, which brings significant synchronization issues across platforms, and, potentially, the use of multi-factor authentication such as SmartCards and biometrics.
The growing threat of identity theft, and a growing Internet marketplace that demands secured transactions and a level of consumer trust in order to function, bring similar challenges and regulations. The Visa organization now requires its vendors and transaction clearing houses meet certain regulatory standards, which drive transactional and user-authentication security.
In addition to trading with customers online, many companies today are extending their infrastructure to the Internet and extranet, to improve accessibility and productivity to employees and business partners. These rewards also carry risks, and to mitigate those risks, as with the other scenarios mentioned above, companies must ensure the authenticity of their users, improve transactional security over insecure networks, be able to detect intrusions and/or tampering, and, in the event that there are issues, be able to locate the responsible source.
IDm helps in many of these areas. Automated provisioning and deprovisioning of accounts and permissions improves the accuracy of data held about individuals, by ensuring that they have access only to what their role requires, and by providing an audit trail. The automation of these processes significantly reduces operating costs as they relate to user management, and it ensures prompt and consistent application of permissions (or revocation) for an individual or a large number of users, frequently without IT interaction. For example, if HR terminates an employee, that change in the HR system automatically disables all of that person's accounts, building access, voice mail, and so forth, across multiple systems.
Retail and Hospitality organizations face similar problems to those mentioned in the previous section; however, their problems are magnified. The user base is highly geographically dispersed, over low bandwidth communications, between the corporate datacenter and the satellite location, and there is rarely any IT administration staff at the remote site.
A staff turnover rate of over 100% is not unusual in these industries, resulting in many more object adds and deletes than is typical in other industries. Seasonal and part-time staff members who do not access systems on a daily basis are more likely to forget their passwords than a typical office worker.
Many Retail and Hospitality companies may trade under different identities or brands that they may want to accommodate in a single IT infrastructure; or, conversely, they may want to keep these completely separate, due to a high rate of corporate acquisition and divestiture, yet want to facilitate communication and collaboration between the brands.
Retailers in particular have a long technology refresh cycle, often operating for 7–10 years on the same platform before considering a technology refresh. In many cases, legacy systems still considered adequate remain in servers and are supplemented with new systems. Consequently, a diverse array of platforms and directories tend to exist at any one time. As mentioned previously, this can significantly increase the cost of operations and the potential for a loss of data integrity across systems.
One of the fastest-growing application spaces is that of portals. Many companies will present everything an employee needs directly on their portal home page, whether they need real-time stock levels, price lookups, merchandizing information, or online training and HR profile updates. To enable this functionality, each user must be uniquely identifiable. In addition to business functionality, corporate compliance requirements are leading more companies to institute "one user, one ID" policies to ensure individual accountability. This means that they can no longer use the generic IDs that they used to use.
This particular industry segment is probably one of the most demanding in its need for role-based privileges, where users are expected to have certain permissions based on their role. This requires some form of IDm solution to facilitate the user in role-mapping based on information in other systems, such as HR.
There are several common scenarios that can be addressed with identity management.
"Classic" Meta-Directory and Automated Provisioning
A meta-directory facilitates the aggregation of identities from multiple sources, and the synchronization of attributes to ensure consistency and accuracy of information held about the objects. Typically, specific directories or sources will be defined as authoritative for an object or attribute, to ensure that, in the event of a conflict, the appropriate source wins. For example, the HR system is typically authoritative for the user object, which contains information such as name, date of birth, Social Security number, and so on. The phone system is authoritative for the telephone extension—if the two systems disagree on the user's phone number, the phone system wins, and the HR system is updated to match the phone system. This is referred to as precedence. Similarly, the e-mail system is authoritative for the e-mail address, and the building security system or property management system is authoritative for the current badge number, and so forth. Figure 2 illustrates such a "classic" meta-directory.
Figure 2. Classic meta-directory
Any changes in connected directories are brokered and updated as appropriate in the meta-directory, and these changes are flowed to other connected directories that contain that piece of information (not all connected directories will contain all information). In this way, the meta-directory holds all attributes available about an object.
IDm solutions vary from the exceedingly simple (if user A exists in Directory X, duplicate the object and all attributes to Directory Y), to the exceedingly complex, with conditional processing, attribute manipulation, and execution of external code on remote systems. In addition to simple provisioning and deprovisioning, an IDm solution should also be able to re-provision based on a change in attributes. For example, suppose that user A changes division, and the HR system is updated. It may be necessary to deprovision the user's account in Forest 1, and recreate it in Forest 2. Furthermore, the user's mailbox must be moved, and different group memberships and permissions must be applied.
By automating the processes, administrative costs are significantly reduced (both in creation and maintenance of objects across systems), data integrity is increased, and the option of role-based management is introduced. A single point of management is also provided for internal, inter-business unit/division, and extranet identity management. Account creation turnaround speed can be increased, in many cases eliminating IT hands-on involvement. Security is improved by ensuring appropriate group membership, permission application, and prompt account disablement if a user leaves the company. This also provides a sound audit trail for object creation and permission.
E-mail and Collaboration
In organizations where multiple directories exist—either by design, evolution, or acquisition—something as simple as looking up a user's e-mail address or collaborating using a portal becomes a challenge. Using an IDm solution allows organizations to build a global address list, whether it is used for e-mail address location, simple phone and address lookup, or to combine address lists from multiple e-mail systems and/or platforms.
In addition to simple lookup, the IDm solution also provides automated Distribution List management, irrespective of which e-mail system users reside on, based on particular attributes of the user, such as location or department.
As with the classic meta-directory, this reduces management costs for what would otherwise be a manual process, and it provides more reliable enterprise collaboration.
Multi-forest Active Directory
In the specific case of AD, in addition to facilitating a consolidated global address list (GAL) for Exchange users, the IDm solution is also used to reduce management costs in other areas of the infrastructure management where AD forests overlap. Site definitions, subnet definitions, printers, and other AD objects can be synchronized between different forests, to reduce management overhead and improve data integrity, which may otherwise be compromised if these definitions are duplicated manually.
As mentioned earlier in this document, password resets are a significant recurring cost to a company's IT group, and this cost increases with each additional directory in the organization. An IDm solution can significantly reduce these costs by presenting a single point of management, where the service desk can reset passwords on all systems from one screen, and users can perform self-service updates or have a password change synchronized from their primary system.
Retail and Hospitality Scenarios
All of the scenarios mentioned above are relevant to the Retail and Hospitality sector. In addition, many other scenarios commonly encountered due to the sector's geographic dispersal are easily accommodated. This includes scenarios where HR administration of a centralized system is devolved to the stores or region; or where the HR system is centrally managed, but the HR department does not want to manage the employee's role within the store, because that can change on a regular basis.
The solution can take many forms, but all of them are accomplished by leveraging an IDm solution. In one example, a medium-sized supermarket chain consisting of approximately 170 stores, 68,000 store staff in 520 roles, with 30,000 mailboxes, and 120,000 e-mail Distribution Lists was experiencing around 120% staff turnover each year. Depending on their roles, staff may need access to the legacy Novell File and Print and GroupWise environment, the IBM mainframe, their new AD, Exchange, the SharePoint Portal (various views by role), and a number of other systems. They implemented an IDm solution fed by the HR system, which provided basic information about the employees and the stores in which they worked. The IDm provisioned data into a database to which the store-based staffing managers had access, thus enabling them to allocate roles and other information to the employee. Based on this information, the IDm then provisioned accounts in the relevant systems, with appropriate group membership and permissions for their role.
This provided the retailer with several benefits: reduced operational cost for creating and managing users accounts; timely permission application or removal; store-level management of details that changed regularly, without having to grant access to the central HR system; role-specific views of the store portal application; and detailed information for security audits—including which users had access to resources, and who authorized that access.
Microsoft Identity Integration Server (MIIS) is the Microsoft identity management solution. It consists of a database of consolidated identity information pulled from various systems and reconciled (this is known as the MetaVerse [MV]), an update engine, Management Agents (MAs) that provide the interface to each of the Connected Directories (CDs), and the Connector Space (CS), which is effectively a buffer database between the CD and MV, where various representations of the CD data are transitively stored.
In Figure 3, a new employee is presented by the HR system (in this case, PeopleSoft running on Oracle), which is imported ("staged") in to the CS. If the object does not exist in the MetaVerse, it is created ("projected") there, and a permanent relationship is formed between the object in the CS and the MV. MIIS then creates ("provision") the object in the AD Connector Space, and the object is then exported to AD. The object's attributes are flowed separately, after the object creation, based on any precedence rules. This simplifies the process, because an object will probably be created only once, but attributes may be updated many times. Attributes in different directories may be identified by different names, and therefore attribute flow is defined by a mapping process during the Management Agent configuration. For example, the HR system may contain "LastName," and Active Directory refers to that by the X.500 name, "sn" (surname); similarly, "FirstName" is "givenName."
Figure 3. Simple object and attribute flow
In this case, the AD MA is a "call-based" MA. Call-based MAs leverage directory APIs and have more intelligence than flat-file MAs. A call-based MA will confirm that the update was successful, and it will flag the queued update as complete in the CS. If it fails, the MA will continue to try to update the Connected Directory until the CS transaction is flagged complete. Call-based MAs can generally determine differences between records, so that if only certain fields have been updated, only the changed field(s) and any required record identifiers will be transmitted by the source directory.
Object creation does not have to originate from a single source. Although in the example, HR is authoritative for the user object, new objects could originate in other directories. A frequent comment has been, "HR takes two weeks to enter a new employee, but the new hire starts work tomorrow. How can we grant them access to the resources they need?"
Assuming that HR cannot expedite the entry, there are options—the user may be added through traditional methods (Admin User Interface, Self Services website, and so forth) into a non-authoritative directory, in this case AD. The options come in how to process the updates—potentially, MIIS could provision accounts based on the AD object into any directories that the user's role may require. For example, this may include the HR system if the employee number can be calculated or a callout to an external routine can be made, thus allowing a valid employee number to be generated.
If the HR system cannot be updated, whether from a technology standpoint or a policy standpoint, directories that are not dependent on HR-specific information may still be selectively provisioned (conditionally provisioned based on the presence or content of an attribute), and when the employee is added to HR, he or she is then "joined" to the MV in the same manner mentioned in the next section, and other directories requiring HR-specific data can then be conditionally provisioned.
In what is a high-staff-turnover industry segment, this may allow stores or locations to add their "new hires" directly to the required systems with minimal HR involvement, to expedite access.
Using the preceding example, when the object is imported into the CS from the HR system, if the user already exists in the MV, a join is performed between the CS and MV objects, forming a permanent relationship between the HR and the pre-existing object in the MV. This is typical when MIIS is first being implemented and several directories are already populated.
This join happens automatically where two objects can be programmatically identified as the same by a common attribute (such as employee number), or by a combination of fields (such as last name, first name, location, phone number, and so forth). If a programmatic join cannot be determined, a manual join can be determined. This is also permanent, unless it is manually removed. Once joined, the attributes of the objects will flow freely, based on the defined flow and precedence rules.
Updating an Object
As in the previous two examples, attribute flow is separated from the object creation or joining operation. Attribute updates are flowed to the MV from the directory that has been updated, based on the defined precedence rules—if the updated attribute flow has precedence over existing sources or conflicting updates, the update will be applied to the MV.
Figure 4. Bi-directional object and attribute flow
Where a call-based Management Agent is used, generally only the changes (deltas) to the identities will be flowed to the MV. In other circumstances, however, the whole dataset may be imported, and then the adds, changes, and deletes to the objects are calculated and flowed to the MV.
The updated attributes will then flow out to connected directories that contain that same attribute. Call-based MAs will confirm the update back to the MA. Flat File MAs require a "confirming import," which imports the data from the CD and compares it to the intended update, to ensure that it was applied. Once the update is confirmed, it is flagged as complete.
Deleting an Object
From a process standpoint, rather than from a technical standpoint, deletion is generally a little more complicated. In most cases, companies do not want to immediately delete user accounts, mailboxes, and so on when an employee is flagged as no longer active in the HR system. This is because it usually takes time to archive or transfer data or mail after the employee's departure. In this case, accounts should be set as disabled rather than deleted, and a deletion date should be established in the MV. Once this date occurs, the objects can then be flushed from all (or some) of the directories, as appropriate.
Simple Attribute Flow Versus Extensions
Simple attribute flows can be configured, using the standard MIIS user interface, from attribute pick lists where they are of the same format—for example,
HRsys.FirstName=AD.givenName. This probably applies to 80% of the attributes that may be flowed.
Where simple flow attribute does not meet the requirements, very simple scripting in any supported .NET language can be used, based on comprehensive predefined templates that are referred to as Extensions.
This may include composite fields such as:
DisplayName=LastName + ", " + FirstName + " " + Initial
Or conditional updates:
If gender = "M" Prefix = "Mr." Endif
Syntax will vary by language, and the complexity of the statements will vary, based on the requirements.
Where pieces of code already exist to perform certain functions, such as Employee Number generation, or where an API for a system is exposed, calls can be made from within the MIIS extension to those external elements.
Included Management Agents
Connectivity capabilities of MIIS 2003
|Type of System||Examples|
|Network operating systems and directory services||Microsoft Windows NT, Active Directory directory services, Active Directory Application Mode, IBM Directory Server, Novell eDirectory, RACF, SunONE/iPlanet Directory, X.500 systems, and other meta-directory products|
|Lotus Notes and Domino, Microsoft Exchange 5.5|
|Application||PeopleSoft, SAP, ERP, telephone switches, XML-based and DSML-based systems|
|Database||Microsoft SQL Server, Oracle, Informix, dBase, IBM DB2|
|File-based||DSMLv2, LDIF, CSV, delimited, fixed width, attribute value pairs|
Third-Party Management Agents and Add-Ons
There are many Microsoft partners providing additional Management Agents for MIIS. Quest Software provides a Management Agent that ties together their ActiveRoles Server product and MIIS, providing a very comprehensive solution for roles-based management.
Single Sign-On (SSO) means many things to many people. What it is perceived to mean, in its simplest terms, is that if a user signs on once, he or she can have access to all his or her systems and resources, without having to log on subsequently.
The only true SSO is the ideal situation where there is only one directory for authentication, even if it is accessed using a variety of methods, such as LDAP.
Most SSO solutions work by performing proxy logons. This means performing an initial authentication using the SSO solution's own, or a central, authentication source, and then passing stored credentials (typically, user ID and password) to the target system through standard APIs (if available), or by automating input to standard logon screens. In this case, the ID and password may have no correlation to the ID and password that the user enters, bringing additional complexity to performing multi-directory password resets or attribute updates. To handle this, some SSO products will place an agent on the target system, which replaces the standard authentication mechanisms.
Although IDm can simplify logon, it is not in itself an SSO solution. In a pure IDm solution, identity information, including passwords, can be synchronized across multiple platforms, but the information must meet the constraints of the target system. For instance, RACF user IDs cannot start with a numeric character. The user must log on to each discrete system, but should have common passwords and potentially common IDs. An IDm solution can be implemented in conjunction with an SSO solution, or by using AD federation to provide an end-to-end solution.
SSO does work particularly well in the Web-enabled application space, where interfaces can more easily be leveraged seamlessly. This is seen frequently in store portals, where users are presented with customized information particular to their role, and also have links to Web-enabled applications and Web Services through the portal, thus giving users a single source for all their day-to-day information needs.
Many retailers and hospitality providers cross organizational boundaries for collaboration or resource access. This may occur with suppliers and customers, or internally, where different brands or business units may be on different directory infrastructures. There are several common approaches to grant an external user access to local resources, or the other way around.
Where the systems were internal to the company, on the same LAN/WAN infrastructure and running on a Windows platform, trusts could be established either between domains, or—if both groups are running Windows 2003—between forests. Permissions could then be granted as appropriate.
In extranet scenarios, the external users would typically be either added to the internal directory implementation alongside intranet users, or in an isolated directory such as Active Directory, ADAM (Active Directory Application Mode), or another LDAP-enabled directory. This adds additional load to the account administrators, and typically presents security challenges if the partner company does not relay deprovisioning requests when employees leave their company, or if they have generic corporate accounts that lack the required accountability.
With the release of Windows 2003 R2 Active Directory, Federation Services are integrated into the product. This allows trust relationships to be established between separate and potentially dissimilar infrastructures and/or directories that support the federated model. The relationship facilitates the flow of identity and policy information between disparate organizations. As with the original Windows trust model, identities are still managed by their own organizations, but they are able to securely exchange identity information and credentials with other members. The federated system can also securely exchange information about services offered to federated partners, acceptable credentials, policies, and so on. Industry leaders are developing standards and specification for Web Services to further leverage the federation model, allowing greater interoperability between a business, its partners, and mobile and remote employees.
The Retail and Hospitality industries have challenges similar to other industries; however, those issues are magnified—more staff, higher staff turnover, more seasonal staff, higher password reset rate, more systems, more directories, more geographically dispersed locations, low bandwidth between locations, fewer trained staff at satellite locations, and IT budgets that are among the lowest in industry. In addition to failing to meet compliance and security needs, manual IDm can be exceedingly expensive and error-prone. An automated IDm solution can reduce operational costs for user and resource management, increase data accuracy and integrity, and also aid in meeting compliance goals for resource access auditing, and for security compliance and enforcement. With an automated IDm solution, all of these objectives can be achieved while minimizing the cost to IT, not only for direct operational costs, but also for security and auditing.
Microsoft Identity Integration Server
Microsoft Retail and Hospitality
Active Directory Federation Services
Quest ActiveRoles Server and QuickConnect for Active Roles Server
About the Author
Mark Scanlan is a solution Architect focused on infrastructure solutions for the Microsoft Services' Retail and Hospitality Solutions Group and Commercial Sector team.
Mark joined Microsoft from IBM's Enterprise Solutions for Microsoft Technologies group, and also spent several years as a founding member of Amdahl/Fujitsu's Microsoft Services practice. In his 20 years in the IT industry, Mark has worked in a diverse set of industry-focused teams in Europe and the United States, including Oil and Energy, Retail Banking, Credit and Mortgage Services, High-Tech manufacturing, State and Local Government, Education, and Healthcare.
Mark attended the IT Institute at the University of Salford in the UK. He moved from England to California in 1996. Mark currently lives in New England with his family.