Improving WIF’s Claims-based Authorization - Part 3 (Usage)
- by Your DisplayName here!
In the previous posts I showed off some of the additions I made to WIF’s authorization
infrastructure. I now want to show some samples how I actually use these extensions.
The following code snippets are from Thinktecture.IdentityServer on
Codeplex.
The following shows the MVC attribute on the WS-Federation controller:
[ClaimsAuthorize(Constants.Actions.Issue, Constants.Resources.WSFederation)]
public class WSFederationController : Controller
or…
[ClaimsAuthorize(Constants.Actions.Administration, Constants.Resources.RelyingParty)]
public class RelyingPartiesAdminController : Controller
In other places I used the imperative approach (e.g. the WRAP endpoint):
if (!ClaimsAuthorize.CheckAccess(principal, Constants.Actions.Issue, Constants.Resources.WRAP))
{
Tracing.Error("User
not authorized");
return new UnauthorizedResult("WRAP", true);
}
For the WCF WS-Trust endpoints I decided to use the per-request approach since the
SOAP actions are well defined here. The corresponding authorization manager roughly
looks like this:
public class AuthorizationManager : ClaimsAuthorizationManager
{
public override bool CheckAccess(AuthorizationContext context)
{
var action
= context.Action.First();
var id
= context.Principal.Identities.First();
//
if application authorization request
if (action.ClaimType.Equals(ClaimsAuthorize.ActionType))
{
return AuthorizeCore(action,
context.Resource, context.Principal.Identity as IClaimsIdentity);
}
//
if ws-trust issue request
if (action.Value.Equals(WSTrust13Constants.Actions.Issue))
{
return AuthorizeTokenIssuance(new Collection<Claim>
{ new Claim(ClaimsAuthorize.ResourceType, Constants.Resources.WSTrust)
}, id);
}
return base.CheckAccess(context);
}
}
You see that it is really easy now to distinguish between per-request and application
authorization which makes the overall design much easier.
HTH
