While the design approach given in Strembeck's work was comprehensive enough to be realized on .Net, the default implementation (done on XoTcl) used extensive patterns from the language (e.g. ability to use an object as a class!), so a quick port of that to a complete .Net implementation of the design would have taken a bit of an effort in my current project.
Well, instead of then implementing the solution, I selected MS Authorization Manager (I know folks will say, Dah... that would have been a no brainer). This is a small library and a management console prrovided on Windows 2003 and 2000 that implements most of the RBAC requirements.

Drawbacks in AzMan implementation

1. One drawback of AzMan (A zee man not Ass man, short for Authorization manager) is its MMC based model that is very administrators centric, while
RBAC being a business model driven artifact rather requires a more user centric admin functions ( e.g. a website driven system would require a web interface mangement of RBAC model).

2. The AzMan implementation is integrated seamlessly with the Windows integrated Authentication model, which in my own opinion is a best way to support Single-Sign On model on enterprise solutions utilizing distributed web services, also the fact that it can be configured with only using Kerberos behind the scene). In many solution using windows integrated authentication may not be an option, and that was the case in our solution as well (this is also true when you can't use windows PDC which is mandatory for Kerberos based authentication).

Overcoming the above two drawbacks
------------
1. To overcome the first drawback, the API driven model of AzMan library can easily be used via a custom admin interface.

As a matter of fact the built-in web configuration management tool in ASP.Net 2.0 utilizing the Role Provider model relies on such approach.

2. The second drawback is somewhat solved by AzMan through using a custom SID encoding mechanism where you can create custom SID for your database driven users and register that in AzMan store. The problem with that is that you will then definitely need a custom Admin interface because AzMan default MMC do not support custom SID.

Solution
--------
So, one solution then is to build a custom Admin interface which plugs in with the custom user membership database and use AzMan APIs to manage roles and memberships.

One can argue why not use the default Asp.Net 2.0 role management provider could have worked, but that abstraction lacks the primary reason of using AzMan, the Permissions (which is a core concept in XoRBAC and RBAC), also it can't authorize against custom user databases, i.e. it can only work with windows integrated authentication.

Also, due to the use of technologies that are potentially at the early stages of their evoluttion, we wanted a more intent/attribute based access to RBAC, so that in future we can swap the backend of RBAC with any other solution.

To some extant the PrincipalPermission attribute in .Net will help, but again it is only role centric not permission centric. For this we developed custom attributes for representing RBACPermission and RBACRoleCheck.

This allowed a more meta driven code that can also be used to generate the AzMan store through reflection as a post build event. One drawback of RBACPermission attribute is that it will depend on ContextBoundObject use of interception that can incurr some overhead. In that perspective one should be able to use CLR built-in PrinicpalPermission approach, though again it is role centric vs Permssion centric.

In later post I will describe further in details on the RBACPermission custom attribute, I may post an article on this, please comment if you think this was a valuable post and need further details on approach.

Few links :

msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager/

msdn2.microsoft.com/en-us/library/system.security.permissions.principalpermission.aspx

Concept used include Custom Identity management in ASP.net Attribute based programming