Ten steps to a federated architecture

If you are responsible for transforming your enterprise architecture, follow these 10 steps to design and implement a federated architecture.

1. Establish a reference model. Base it upon a security design pattern of brokered authentication, requiring the architectural components to be isolated and well defined.

2. Perform SSO vendor evaluation. There are many SSO vendors and services on the market. Define your requirements up front, for example, who are your users, how will they be accessing apps, where do the apps reside (on-premise, in the cloud).

3. Integrate the SSO Identity Provider (IdP) Server. Once the vendor has been selected, the IdP server must be integrated into the existing infrastructure, including audit logging, systems monitoring, and host based intrusion detection. Also make sure the IdP server meets requirements for business continuity and system hardening.

4. Isolate the Service Provider (SP) or Relying Party (RP) from the IdP. Many legacy applications integrate directly with the authentication service (e.g. Active Directory, LDAP). Isolate the SP/RP application from the IdP to achieve brokered authentication.

5. Identify security domains. The security domains will define the applications and services leveraging the brokered authentication services. Identify existing security domains, including cloud vendors.

6. Establish federation versus centralization. The goal is to provide a secure open architecture while transforming services to the cloud. SOA/Cloud is a business model as much as it is a technology. Business modeling needs to defines applications and services in such a manner that supports federation across the cloud versus tightly coupled business processes.

7. Establish a reference implementation. The reference implementation defines the type of security tokens, protocols, bindings, and policies. Select the security token type based on the technical requirements, for example, SAML for large bandwidth services and OAuth for mobile devices.

8. Define the security token attribute contract. The attribute contract defines security claims for the subject (e.g. user identity), where the claims come in the form of roles and entitlements.

9. Define roles across security domains. Role-based Access Control (RBAC) is an approach for restricting system access to authorized users and can be used where the business has stable, well-defined job functions across multiple functional and application areas. Define the roles and permissions that can be used by the SP/RP for access control and assign roles to users.

10. Modify applications. The isolation of the SP/RP from the IdP, requires that the application can receive security tokens that assert authentication to the application hosting container. Applications should be able to provision a user account via “just in time” information from a security token, however many legacy applications may require advanced user provisioning and de-provisioning capabilities. If necessary, consider granular access control based on security token roles and entitlements allowing the IdP to manage authorization for the enterprise versus each application.