One of the challenges for authenticated services provided across your entire enterprise is identifying the appropriate credentials to use, for both ease-of-use for users as well as for sustainable manageability.
For organisations with a single central user directory, such as an enterprise-wide ActiveDirectory, this can be relatively straightforward. In other organisations, there may be separate divisional authentication systems, without a single global user directory.
This means there are a few options for providing a global service within the enterprise, all with associated complexity and tradeoffs:
* One can create a new central directory, and either have users create accounts, or pre-populate it from existing stores. However, if the existing divisional authentication systems continue to exist, this creates both a potential source of confusion (as users now have at least two accounts) as well as a possible synchronisation issue as both divisional and central user accounts now need to be maintained.
* One can federate across the various authentication systems, using e.g. Active Directory Federation Services or various LDAP federation approaches.
* One can use Shibboleth or other distributed authentication systems, where trust relationships allow the individual divisions to continue to maintain the credentials, but act as trusted authentication providers to other parts of the enterprise.
Within the Government of Canada, there are a number of potential approaches that could be taken to solve this problem. For example, there is a PKI credential that can be created, attached to the globally-unique employee identifer (the PRI). This is called myKEY... except it seems this branding is also used to describe a variety of legacy PKI systems within the government as well, so the situation is somewhat muddied.
Where this starts to get really complicated is when you want to have different levels of user rights, with e.g. closed groups with administrators, managers and contributors, and when you want to make this work in proprietary systems (which often have robust rights management, but using proprietary internal user account management) or across organisation boundaries, e.g. an extranet site that allows both internal users and external users.
As well, a federated solution means one has to deal with all of the varying privacy, security, and personal information standards of all the different divisions. In such a situation, "can we use these credentials for X?" can become a difficult question to answer.
Beyond that, ideally we would like federated search to be able to return results for all content that a user has access to (including closed groups that they participate in). I'm not sure how to manage this, effectively it means the central search service has to be able to act as an authenticated proxy-user for every single user.
For external collaboration, do we need to consider something like the (controversial) Identity Ecosystem proposed by the US government? How do we allow Canadian citizens to participate in a trusted way in online government consultations, while ensuring that both their privacy is protected (so we probably don't want to share credentials with health or tax systems) and that they actually are Canadians?
Another issue is internal sustainability, for example, tightly binding to myKEY means that there needs to be a clear sustainability and evolution plan for those credentials. If not, we run a danger of locking ourselves into a particular authentication solution. To avoid this, one needs to find a way to loosely couple to an authentication service, but this can be difficult if you are seeking very granular user permissions and identification information.
For the moment, we are simply having users create separate accounts for new cross-division (enterprise global) systems but this is not sustainable. Even attaching accounts to approved government email addresses is not sustainable, as currently the email address changes when users change departments. I would be interested in hearing how other organisations are managing this (particularly for internal Government 2.0 services, such as government-internal wikis and discussion fora). Is GovDex using user-created accounts attached to government email addresses? Are there any best practices?
![[add RSS feed]](http://www.feedburner.com/fb/images/pub/fb_pwrd8831.gif)
![[add RSS feed]](http://www.feedburner.com/fb/images/pub/feed-icon32x32.png)
Recent Comments