Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You have several options:</p> <ol> <li><p>The simplest one is the ClaimsAuthorizationManager, which might be what you're looking for. <a href="http://msdn.microsoft.com/en-us/library/ee748497.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ee748497.aspx</a> The CAM is a step in the ASP.NET authentication pipeline that runs right after your application has validated the security token incoming from ACS. Here is where you define your custom authorization logic, and you can add additional claims to the IClaimsPrincipal that gets delivered to yor application. Instead of centralizing authorization logic in a service, you could for example implement your CAM in a library that's shared accross various relying party applications.</p></li> <li><p>If your authorization rules are simple, i.e., you're not querying any external user attribute store, then one option would be to use ACS claims transformation rules to do this. Then your applications would consume the token issued by ACS directly. <a href="http://msdn.microsoft.com/en-us/library/gg185955.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/gg185955.aspx</a></p></li> <li><p>If however your architecture absolutely requires a separate login service that consumes tokens and populates new tokens with user attributes and such, then it will need to be an STS. Building your own STS can be tricky, but there are prefabricated STSes available to do this. If your applications live in an AD domain for example, ADFS 2.0 would be an ideal choice because of it's close integration with AD and ACS, and it's powerful claims transformation capabilities.</p></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload