Don’t get locked into a single identity ecosystem. There will invariably be internal and external applications that don’t naturally fit, and there may be a replacement for SAML someday, or you may simply wish to switch software or hosting.
To maximize the possibility of future migration, ensure that your
entityID is in a domain you control and that discovery is based on your domain.
Certain environments and use cases lend themselves naturally to a form of federated identity known as federation, where all participants agree to common rules and exchange trust data centrally. This has been most commonly seen deployed in academia, conglomerates, and distributed organizations such as sports leagues.
While the trust topology is not easy to set up and doesn’t fit every use case, it can trivialize integration and maintenance processes. A single, central registry allows a provider to publish a new signing key, for instance. That lets an IdP be confident that all services will receive the new metadata before the key changes.
Signet’s principals were responsible for the creation of the first federation, and we haven’t stopped building and learning along the way. If your organization structure looks a bit like a federation, then the technical version may suit you well, and Signet is the deepest expert in this field.
As identity exists to serve applications, the application should set the pace and requirements for authentication. Please involve the identity management team as early in the procurement or development process as possible. A couple trivial decisions with no other practical impact can save a lot of future wiring.
It’s common for login to be blamed as a stopper in a project, but it rarely is. The agglomeration of user data or the implementation of access controls may be a challenge, but a reliable IdP should be taken as a given. The functional lead of the project is the best leader for all aspects of the integration, including authentication and authorization, the requirements for them, and deadlines.
What’s the first thing that you see when a service is broken? Almost inevitably, a login page that is apparently not functioning. The login system is the first point of interface for many applications. As a result, it’s also the most probable component of any integration to end up throwing errors when something goes down. This makes many problems in other systems end up looking like login problems.
While it will be generally impossible to explain your predicament to the user, you should be very careful to convey this to management and incident response.
In fact, the identity management system’s logs may offer the best chance at tracking down the real cause of any integration failures.
Nevertheless, never make a simplistic assumption that the login system is down. Investigate and troubleshoot with all involved components in mind.