Nov 1, 2009 at 6:35 PM
Edited Nov 1, 2009 at 6:36 PM
I don't see why these couldn't work together. You would need an assertion on an endpoint policy that configured the AzMan role provider (included in the security guide). Then you would need to modified the underlying implementation of the RoleProviderAuthorizationElement
assertion type (also in the security guide) that looked at a claim in the certificate to obtain whatever you wanted to use as the "user name" (likely the identity claim). The current implementation uses ServiceSecurityContext.PrimaryIdentity.Name.
The rest of the role authorization assertion type should work ok since it retrieves whatever role provider was configured and calls GetRolesForUser(). It doesn't care if the provider is the SQL Provider, AzMan, etc.
The existing role authorization assertion type implements role checks in two ways so that you can perform authorization at either the virtual service endpoint or on the outbound channel that will invoke the resource. You'd want to modify both locations
where role checks are performed so that a claim is used rather than the PrimaryIdentyt.Name value.
Take a look at RoleProviderServiceAuthorizationManager and RoleProviderAuthorizationParameterInspector classes in the security guide source code. Both have the following lines of code (simplified for clarity):
RoleProviderServiceHostExtension roleExtension =
string userName =
string userRoles = roleExtension.Provider.GetRolesForUser(userName);
The second line is the one you'd want to modify so that a claim from the client certificate is used in place of the user name.