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