In the continuing Baby Steps to SOA series, we follow Doug and his IT team behind BuyMyWidget.com as they take steps to renovate their digital asset architecture. Previously, we introduced the problem and the team, started planning and analysis, decided on some metrics, refactored the website applications, and now we continue on our travel through the road map with tackling identity management!
The Evolutionary Roadmap
- Step One: Analyze and Plan
- Step Two: Measure It
- Step Three: Three Tiers for the Website
- Step Four: Single Sign-On
- Step Five: The Move to a CMS
- Step Six: Data Services
- Step Seven: Centralizing eCommerce
- Step Eight: Sharing the Business Tier
- Step Nine: Moving beyond the website
- Step Ten: Riding the ESB
Step Four: Single Sign-On
One of the easiest components in a system that can be identified as a distinct service is the logic and data around authentication and authorization. Unfortunately, this is also one of the most difficult to extract from a network of digital assets. Using a Single sign-on (SSO) approach, possibly combined with a federated identity management solution, allows the IT team the ability to centralize authentication into a single service that all systems can use.
There are 4 symptoms that we should attempt to cure:
- Password Fatigue: Too many usernames and passwords for end-users to remember.
- Account Management Overload: Too many different authentication systems that IT needs to manage.
- Distributed Authorization: IT team cannot create a new user and give access to all systems at once.
- Independent Security Domains: Users need to log in to every system as they encounter it.
If SSO is able to be implemented across all systems, this will ensure users need only remember a single credential set and this will provide them access to all systems. Depending on the implementation, the implementation set they need to remember may need to be specific to their point of entry into the network.
Account Management Overload
If one of the symptoms encountered is account management overload, Single Sign-on may not address this symptom directly. While end-users may be able to centrally authenticate, depending on the choice of model for Single Sign-on, this may not centralize the account management. Federated Identity Management can be leveraged to help address this symptom.
There are several ways to allow the IT team to centrally manage authorization to all systems. Custom-built solutions to automate creation of accounts in all systems can help. This involves synchronizing with some central “system of record”. Otherwise, a Federated identity management system will also help address this.
Independent Security Domains
Typically, when multiple products and systems are deployed onto the network, each one maintains its own security domain. From an end-user perspective, most users do not understand the separation between one system and another. This means that we need to support defining a logical security domain that can overlap each individual security domain and allow the end-users to operate within the boundaries that make sense to them, and not forced on them by product-specific restrictions. Token-based systems allow us to implement an understanding as to which systems will be allowed to be accessed once a user logs into the new “joined” security domains.
Federated Identity vs. SSO
Perhaps it is best to quote directly from Wikipedia on this subject:
In Information technology (IT), Federated Identity Management (FIdM) falls under the umbrella of Identity management (IdM). It amounts to having a common set of policies, practices and protocols in place to manage the identity and trust into IT users and devices across organizations.
Related to Federated identity Identity management is Single sign-on (SSO), where a user’s authentication process is being used across multiple IT systems or even organizations. Single sign-on is a subset of Federated Identity Management, as it relates only to authentication and is understood on the level of technical interoperability.
FIdM allows users to reuse electronic identities, saves administrators redundant work in maintaining user accounts and provides a consistent, trustworthy infrastructure component.
To serve our end-users immediate needs, moving to an SSO solution will solve their problems, but not necessarily the problems of the IT team. SSO will provide us with the ability to authenticate once and allow multiple systems to accept that authentication. A federated identity will allow us to centralize management of the users. These can be implemented independently, though work best when both are implemented. Depending on the limitations of the systems in play, one or both may not be possible.
In Our Scenario
Previously, Lynn had provided an overview of the systems and the team had highlighted some of the identity management issues:
Most of the systems have their own authentication mechanisms, and the IT folks are finding that identity management is a huge pain. They receive a lot of calls from customers trying to figure out which password and username are used for different systems. Doug reviews his numbers, but doesn’t see any supporting costs in his analysis of this. The IT team explains that this is because the costs are distributed between customer support and the IT support of multiple systems. No single system has a huge cost for this, but together they add up. The IT team suggests implementing a Single Sign-On (SSO) solution to simplify identity management for the users and for the IT team.
Now the team needs to plan out a solution for managing their identities. In their system, they are currently performing an identity synchronization across multiple back-end systems that are used by the internal team. Users still need to log in multiple times as they encounter new systems in the hierarchy. For example, the user accessing the CRM app cannot use the ERP app without logging in again.
On top of this complication is that the team does not want to provide access to all extranet users for all systems. An Intranet is in play on their network, and should only be able to be accessed by internal employees. Users on the eCommerce website should not have access to this internal system. Similarly, extranet users should not be allowed to access the ERP, CRM, or Order Management systems. The Event Website, however, should be in the extranet domain. Extranet users want to be able to pass between these two sites freely.
This suggests that SSO alone will not address the needs of the users. Lynn’s team needs to implement both authentication AND authorization for the multiple systems. The team decides to put together the following plan for their identity management:
- Choose the system of record:
As most of the systems already synchronize with the Active Directory store for internal accounts, the team considers making this the system of record. This means that extranet user accounts would now also be stored in this internal active directory. While this will make life for the IT team easier, it does mean that external systems will be using accounts stored in an internal identity system. This will increase the need for security on the SSO site. In order to minimize security issues during transition, the team decides that the AD store will only be a system of record to the SSO site. All applications will need to go through this central point, and not directly access the AD system.
- Implement federated identity:
The first step will be to build a centralized login application that uses a federated identity protocol such as Windows Identity Foundation. This will require temporarily syncing this system with all other identity systems until all systems have adopted it. The team has chosen WIF because most of the third-party systems they have installed will support it out of the box.
- Federate eCommerce website:
The custom eCommerce website application will be updated to use the centralized login. At this juncture it is likely that adjustments and refactoring will be required to the centralized authentication app to properly support login, logout, and token creation for the eCommerce website.
Once complete, users will still have to login to all systems separately, but now will have a token generated for them to allow for future SSO capabilities.
- Federate Event website:
The next most valuable asset to ensure SSO is applied to is the Event website. Since these are the two revenue-generating sites they should be targeted for initial rollout. At this point, authorization is not an issue since the only systems participating are both extranet systems. Once complete, users should be able to transition between the eCommerce website and Event website seamlessly.
- Federate Order Management application:
This will be the first introduction of a system that extranet users should not have access to. Additionally, order management systems tend to be third-party systems which are more difficult to customize. Co-ordination with the third-party vendor may be required here in order to implement the token consumption. Once implemented, testing will be required to ensure the authorization prevents extranet users from accessing the Order Management system.
- Federate CRM and ERP
The team decides to tackle both the CRM and the ERP at the end, as they are currently both involved in an identity sync operation that keeps them synchronized with the internal Active Directory store. Both of these systems are third-party, and from different vendors. Because the CRM is reaching end-of-life, the vendor is not willing to make any changes to the current CRM system to support WIF. However, the new version of the CRM that Doug will be receiving will have built-in support for WIF. The team decides to delay implementation of the CRM federation and only federate the ERP at this time.
- Update Identity Sync
At this stage, most of the systems now support the federated identity. Synchronization should no longer be needed with anything but those systems (like the CRM) that are not currently able to support the SSO token. The identity sync application should be updated to only need to synchronize the outliers with the central authorization source, which in this case is Active Directory.
How much will this step cost?
In the project, implementation of the SSO and federated identity component is usually one of the less expensive pieces to develop. If you choose a solution that is already supported by your systems then you will not need to spend a large amount of budget on customization of each application.
Sitecore note: Sitecore supports both an AD integration and a WIF module, so if you plan on using Sitecore for your CMS I would recommend going with one of those two options.
If any customization is needed, then your budget will need to accomodate for this. At the low end, assume at least a few weeks per application to design, build, and test. Once the applications begin federating with each other, you will also need a few weeks of security testing to ensure authorization across applications is working correctly.
If your authentication system has high-performance needs, or needs to be highly available, you will also need a few weeks of performance testing as well as infrastructure costs required to make the centralized authentication system highly available.
If you need to deal with third-party vendors for any of this work, they will likely charge for custom development if the solution you have selected is not compatible with their product. These vendors usually charge higher rates for their resources then your own resources cost, although your support agreement may allow you a certain number of days of work per year. Regardless, the cost of having your own team hack together a solution on their product will inevitably cost more, and you can usually get a warranty on the new customization to allow for you to use the vendor to fix any issues with the federation to their product.
This series continues with the team distributing content management into its own system.