On-Premise
If you have already standardized on a traditional technology On-Premise such as Active Directory or LDAP, you may want to retain that on-premise directory as your master identity source. (However, you might not have a choice. Some of the newer identity schemes and IoT environments are incompatible with legacy environments.)
There are hybrid models to consider. One solution is to use your established methods for employees while managing the identities of contractors and guests via a third-party product. The access given to employees is typically more textured, with many more applications and services involved than for temporary workers. Consider managing identities for the latter with a lightweight modern third-party solution. You want to avoid as many adds, moves, and changes as you can with the more complex services such as Active Directory.
Cloud
Many enterprises today operate either wholly in a cloud environment or with a mix of on-premises and cloud-based operations. In the cloud especially, it is common to implement identity as a service (IDaaS).
IDaaS provides cloud-based services that broker IAM functions to target systems on customers’ premises and/or in the cloud. IDaaS is often paired with software as a service (SaaS), implemented as applications in the cloud.
When the movement toward SaaS first began in the late 1990s, authentication was the sticking point, the notable obstacle. As SaaS emerged, it required an enterprise to authorize duplicate accounts (parallel to those already in the enterprise) for its users, on the website of the software service. Maintaining duplicate accounts was troublesome and risky, and the question of who held the passwords (the enterprise or the service company) had no good answer. Using an identity provider in the cloud along with SaaS elegantly resolves this puzzle.
In the identity provider scheme, a user in your organization logs in using an identity from an outside provider, such as Google, Facebook, or Amazon Web Services. That external entity is given permission by your security services to use internal resources on behalf of that validated account. This way, your users can access resources via the cloud without revealing your internal usernames and passwords, or other internal credentials, to third parties in the cloud.
Availability of the identity provider remains a concern, as it always must. Still, will there often be a case when your users want to use cloud software services—which are up—but the cloud-based identity provider is down? Usually, they will both be available; occasionally, they will both be offline due to difficulty in reaching the cloud. The unavailability of the IdP alone should be a rare occurrence.
Federated
To make use of an identity provider across a federated group of partners is a natural extension of the simpler cases. You will need to examine the increased spread of the risks involved, but the business drivers for collaboration are irresistible for most companies in today’s environment.
The key is to be able to give access to selected applications and databases—no more. If those services are hosted in the cloud, configured as SaaS, both your employees and your collaborators can use the same IDaaS. If the services to be shared run on your internal, on-premises servers, you will need your servers to receive, accept, and trust incoming directives (typically, SAML assertions) from your collaborator.
