An application already usually has authentication and authorization functionality built-in. Enhancing or substituting that with federated identity is a craft.
Interface Points
The bare minimum an application must do to participate in federated identity is to be able to receive and properly validate assertions. This limited implementation is often specifically chosen to avoid modifying the user experience for users authenticating through traditional mechanisms. Attributes must be read and used properly, but there isn’t much to do beyond that.
The next layer of enhancement involves direct invocations of actions when they’re needed. For example, a wiki might wish to allow users to browse the same URL space unauthenticated but display different views and grant different rights when attributes are present. The wiki gives users the ability assume the elevated role by logging in off a triggered SAML login, the most basic form of direct interaction with a service provider.
More complex use cases take advantage of other functionalities exposed by the service provider. There are many overt actions that can be triggered by accessing the correct URL in many pieces of SAML software, and there is usually a wide range of interesting data presented in environment variables.
Balance time investment, user experience impact, the importance of federated identity, and other considerations when choosing how tightly to integrate an application with an identity environment. This is more art than science.
User Data Management
Applications frequently have their own notion of user accounts, and federated identities are tied to these local representations. It’s critical to understand which user data has been self-supplied and which is authoritative from the organization, and generally judicious to limit the degree to which users can change information like that received in the assertion.
There are also often grouping or tagging functionalities that enhance user identities within applications. Currently, there exists no good way to write that information back through a federated identity session. Signet anticipates standards to be developed to address this.
Authorization
As the protector of the final resource, the service is always ultimately responsible for authorizing a user. The basis by which the service does this, however, can offload some of the burden. A service may request that no assertion be sent at all for unauthorized users preventing them from even entering the front door.
In general, authorization should occur as close to the resource being protected as possible, and any errors or unmet requirements that arise during the access process should be displayed to the user by the service. This is because the service knows what the user was trying to do, why the user was unable to do it, and what the remediation would be.
The fix will often be on the other end: your IdP may be sending the wrong data for a particular user. But by being at the heart of the authorization decision, the application should have excellent logging and the presumption that it will be the ultimate point of policy enforcement.
Of course, the real world is a sloppy mess of all these approaches with some extra creative ones added. Signet can help your users get properly authorized and the help they need when denied appropriate access.
Granularity
A service needs to carefully decide how it wants to be represented. A university library, for instance, may wish to appear as just another service offered by an entire organization. It may also choose to uniquely identify itself for all library services.
It might dedicate an identifier to each service. Finer granularity allows IdP’s to make specific decisions for that resource, such as enforcing MFA or releasing specific attributes, while coarse granularity reduces overall system complexity and can bring services online with minimal effort. None of these models has proven broad superiority in practice, and you will need to select one.