Mitch's Solution #3Better Delegation Features in Windows
The last call from Mitch was for better delegation features in Windows. But the types of things that Mitch is asking for already exist. If you want to delegate permission to manage a file share, just give a user or group "Full Control" over that share. They can add/remove other users as required. You can do the same thing for a printer. You can perform similar actions within Active Directory (e.g. to delegate the ability to reset passwords for users, or add additional machines to an OU). There's even a handy Delegation of Authority wizard provided to automate the setting of the necessary permissions!

So what are the solutions?
I see solutions for the common user complaints that Mitch has outlined falling into a few categories. Some of these might seem overly complicated, but remember that (a) we need to ensure that whatever solution we implement allows for manageability of increased complexity (b) it offers benefits to end users without compromising the overall security and manageability of the network (c) it scales from small to large enterprises.

First Solution: Provisioning/Deprovisioning Systems
These types of systems typically share a number of features:

  • They abstract the underlying permissions system
  • They can connect to a number of underlying systems
  • They feature workflow
  • They permit delegation, whilst also maintaining a central repository of effective permissions that can be interrogated for reporting purposes (e.g. to determine a user's effective permissions)
  • They can both enable access to systems, as well as remove access to systems.

An example of such a system would be Activate sold by the Innovation guys in NZ. It features a web based interface, workflow provided by Biztalk, and a central storage repository build on SQL Server. The user can request access to a resource, the request would be routed to the relevant delegated authority, who can grant it (again via a web interface). The system itself alters ACLs, creates/deletes mailboxes and so forth. Everything is recorded to that analysis can be performed.

My company Avanade also sells a solution, which is a bit more complex based around ADAM, MIIS, SQL Server, Biztalk. It can connect to disparate systems (such as Active Directory, SAP, Lotus Notes) to either enable access, or disable access. Since the system itself keeps track of what a user has access to, it can easily remove access to all systems a user has permissions to if a user leaves.

This system addresses the needs for getting access to resources

Second Solution: Identity Integration Systems
Products like Microsoft Identity Integration Server (MIIS) help avoid the problem of user's having to juggle multiple passwords/identities within an organization. It can connect to multiple individual systems via connectors and create/set the user's credentials in a synchronized manner. If/when a user needs to change their password, it's changed across all systems, leaving the user with just the one username/password. The systems are extensible, so it's possible to build a workflow on top of them (for example a self-service password reset system).

This system helps address the issue of having too many passwords/identities within an organisation.

Third Solution: Federated Identity Management across business boundaries
Mitch already touched upon standards such as SAML, WS-Security and FIM. These types of solutions allow a user in one business environment access to another business environment via a particular type of trust arrangement via the two. The authentication system (e.g. Active Directory) in one business is able to accept a credential token from the other business environment, without needing to see the user's password. This type of arrangement allows the user to have a single identity across multiple businesses, whilst allowing each business to maintain the effective permissions that the user should have.

In Mitch's last blog post, he alludes to something similar without realizing it, when he mentions the "web of trust". A bank might accept credentials from other organizations e.g. a driver's license or passport. However, what Mitch doesn't acknowledge is that it is still up to the bank to decide whether to permit a particular action (e.g. make a withdrawal). Just because the user is able to successfully authenticate using a foreign-generatewd token, doesn't mean that the bank automatically permits the action. The user might already be overdrawn on their account, and so it is still up to the bank to authorize the action. This is the same principle behind how FIM systems work. Mitch's example hasn't taken us any further down the road than where we've already come.

So, in conclusion (if you're still reading this!), both Mitch and myself realize that things can be improved in the world of end-user provisioning and access to resources. Where I think we differ is in the proposed solutions. I think Mitch's solutions concentrate too much on making things easier for the end-user without considering the overall needs of a secure network. I think the solutions that I've presented are the direction that most firms will be taking as they grapple with user access issues.