Claimed based authentication using OWIN

Claims
Security Flows
OWIN
Code diving

Topics

Getting to Know the Identity of .NET 4.5

Where Did We Come From?

Cornerstone of authorization in the last decade

public interface IIdentity
{
    string AuthenticationType {get;}
    bool IsAuthenticated {get;}
    string Name {get;}
}

public interface IPrincipal
{
    IIdentity Identity {get;}
    bool IsInRole(string role);
}

var principal = WindowsPrincipal.GetCurrent();
if (principal.IsInRole("Sales") == false)
{
    // Do something.
}
else
{
    // Access denied or do something else.
}

public void SomeMethodUsingPrincipalPermission()
{
    // Throw exception if not authorized.
    new PrincipalPermission(null, "Sales").Demand();
      
    // Do something.
}
      
[PrincipalPermission(SecurityAction.Demand, Role = "Sales")]
public void SomeMethodUsingPrincipalPermission()
{
    // Attibute throws exception if not authorized.
    // Do something.
}

Drawback:

authorization checks are embedded within the code, and authorization checks only work with role information.

var principal = WindowsPrincipal.GetCurrent();
if (principal.IsInRole("Sales") == false)
{
    // Do something.
}
else
{
    // Access denied or do something else.
}

public void SomeMethodUsingPrincipalPermission()
{
    // Throw exception if not authorized.
    new PrincipalPermission(null, "Sales").Demand();
      
    // Do something.
}
      
[PrincipalPermission(SecurityAction.Demand, Role = "Sales")]
public void SomeMethodUsingPrincipalPermission()
{
    // Attibute throws exception if not authorized.
    // Do something.
}

The security class structure looked like this through.NET 4.0

public interface IClaimsIdentity
{
    IClaimsIdentity Actor {get; set;}
    SecurityToken BootstrapToken {get; set;}
    ClaimCollection Claims {get;}
    string Label {get; set;}
    string NameClaimType {get; set;}
    string RoleClaimType {get; set;}
      
    IClaimsIdentity Copy();
}

public interface IClaimsPrincipal
{
    ClaimsIndentityCollection Identities {get;}
      
    IClaimsPrincipal Copy();
}

Claims?!

public class Claim
{
    public virtual string ClaimType {get;}
    public virtual string Issuer {get;}
    public virtual string OriginalIssuer {get;}
    public virtual IDictionary<string,string> Properties {get;}
    public virtual IClaimsIdentity Subject {get;}
    public virtual string Value {get;}
    public virtual string ValueType {get;}
      
    // Methods omitted for brevity.
}

From WIF to .NET 4.5

system.security.principal

This is the security class structure in .NET 4.5.

Claims-Aware Web Application (Active)

(demo)

Security Protocols

Integrated Windows Authentication

- Accounts

- Usergroups

ASP.NET membership and roles provider

- user names

- passwords

- roles

CLAIMS

ISSUER

(AUTHORITY)

Terminology

Service Provider (Resource Server) - this is the web-server you are trying to access information on
Identity Provider (Authorization Server) - this is the server that owns the user identities and credentials. It's who the user actually authenticates with
Security Token Service (STS) - is a software based identity provider responsible for issuing security tokens, especially software tokens, as part of a claims-based identity system.

Smart Client - this is how the user is interacting with the Resource Server, with a native application
Passive client - this is how the user is interacting with the Resource Server, with a javascript application
Token - Compressed, encoded, possibly encrypted, and it usually looks like gobbly-gook, key passed to SP on each request