This document introduces best practices for managing users, identity attributes and entitlements in a typical consumer-facing Extranet web portal:
- The focus is on organizations who wish to manage a portal that will be accessed by large numbers of "customers."
- The term customers is used in a generic sense. They could be literally customers in the sense of e-commerce, or new patients in a healthcare context, students or applicants in the context of an educational institution, citizens in the context of e-government, etc.
- There are really two deployment patterns in this context:
- One where there is a pre-existing relationship between the organization and consumers. For example, in a typical banking deployment, customers must have a bank account and probably had to visit a bank branch to open one, before web portal access makes sense.
- One where there is no pre-existing relationship between the organization and consumers. For example, college applicants or new store customers likely have no prior relationship with the organization hosting the portal.
- The relationship between the organization and its users is often weak. A customer may never return to the eCommerce web site. A patient may not get ill and visit the hospital again. An applicant may abandon a college application.
- The number of users may be quite large -- reaching into the millions.
- The amount of data about each user is often limited, both because users do not wish to volunteer much information and because there are regulatory reasons to avoid capturing much information.
- The variety and complexity of security entitlements assigned to users is very limited. Few if any roles, probably just a single user object in a single directory, one user cannot access another's profile, etc. There are almost certainly no e-mail folders, home directories, etc.
- The variety of complexity of change processes is likely very limited -- on-boarding, deactivation, password changes, password resets, perhaps profile attribute updates, perhaps out-of-band validation of attributes such as e-mail address or mobile phone number.
The objective of this document is to present best-practices for what information to capture about users in a typical Extranet web portal and business practices for managing this information.
Organizations that are able to adopt best practices processes will benefit both from optimized change management and from reduced total cost associated with automating their processes on an identity and access management (IAM) platform.
Please note that this document is designed to help organizations design the system by which users are added to, managed in and removed from their Extranet (B2C) portal. The scope of this document does not extend to runtime authentication or authorization of users into applications -- that falls under access control rather than identity and access management.
Directories, IAM systems, applications and firewalls
A typical Extranet web portal is accessed over the public Internet and is often deployed to a "DMZ" network segment. Users typically have records in just one system and this system is either a directory (i.e., LDAP) or a database (e.g., MSSQL, Oracle, MySQL, etc.).
Best PracticeUser a directory rather than a database to store user objects, if at all possible. Modern directory products support excellent, WAN-friendly data replication and many applications can externalize authentication to a directory (but not a database).
To support large scale, the user store should be replicated across servers. To ensure service availability in the event of a facility disaster, the user store should be replicated across data centers. The latter -- WAN replication -- is more easily supported by some products than others. In particular, some LDAP directories (such as AD LDS) are easy to configure in a multi-master, multi-site arrangement. Database servers often do support replication but can be quite complex to configure with cross-site replication.
Best PracticeReplicate the directory and IAM system across servers and data centers, to provide more local service to users and to survive disasters.
Best PracticeLoad balance user traffic across multiple, concurrently active IAM systems, with a preference for nearest-server.
For the same reasons, the IAM system should be distributed across servers and data centers.
Combining the above requirements, we get a network architecture such as that shown in Figure [link].
Extranet web portal network architecture