My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Sunday, September 19, 2010
« IIW East Session on Role of Government a... | Main | Federation Flows 2 – Attribute Exposure »

In some of the conversations I’ve had recently, there has occasionally been a sense of confusion around around the options available in federating identities, the separation of concerns between authentication and authorization as well as the choices in how attributes can be passed to applications to make access control decisions.

I am in the process of putting together some material to convey the various options available to us in the current state of technology.  I am starting with authentication. Some caveats:

  • This is conceptual in nature
  • Implementation choices, whether they are architectural or technology, may drive the separation or co-location of some of the conceptual entities noted in the pictures
  • Still a work in progress…

First a definition:  A Domain is a realm of administrative autonomy, authority, or control for subjects and objects in a computing environment.  For the purposes of this discussion, a Trust Domain defines the environment in which a single authority is trusted to validate the credentials presented during authentication. (Thanks Russ!)

Authentication – Direct (Single Trust Domain)

1) The Subject attempts to access the Resource and presents a credential

2) The Resource, prior to authenticating the claimed identity presented in the credential, checks the validity of the credential. This could include: (a) Is the credential issues from a source I trust? (b) Has the credential expired? (c) Has the credential been revoked?  Once the validity of the credential is satisfied, the resource authenticates the Subject by verifying the Subject can prove association to the asserted identity in the credential

Once Authenticated, the resource should then verify that the identity has authorized access to the requested resource, based on existing security policy.

AuthN_Direct_SD_small

 

Authentication – Brokered (Single Trust Domain)

1 and 2) The Subject presents a credential to the Broker. The Broker, prior to authenticating the claimed identity presented in the credential, checks the validity of the credential. This could include: (a) Is the credential issues from a source I trust? (b) Has the credential expired? (c) Has the credential been revoked?  Once the validity of the credential is satisfied, the Broker authenticates the Subject by verifying the Subject can prove association to the asserted identity in the credential. Once this is done, the Subject receives a token with proof-of-authentication .

3) Subject attempts to access the Resource and presents the token from the Broker

4) The Resource validates the Subject’s token

Once validated, the resource should then verify that the identity has authorized access to the requested resource, based on existing security policy.

Types of Security Tokens

  • SAML Assertion
  • Kerberos ticket
  • Username token
  • X.509 token
  • WAM Session Token
  • Custom
AuthN_Brokered_SD_small

Authentication – Direct (Cross-Domain/Federated)

This beastie does not exist!

Authentication – Brokered I (Cross-Domain/Federated)

  • Clear separation of security boundaries.
  • Resource B only accepts identity information vouched for by Broker B.
  • Dependency between Subject A and Broker B; If Broker B requires X.509 Certificates as a token, Subject A must have the ability to handle X.509 Certificates
  • Trust between Broker A and Broker B is usually set up before-hand and out-of-band.

1) Subject A presents a credential to the Broker A. Broker A, prior to authenticating the claimed identity presented in the credential, checks the validity of the credential. This could include: (a) Is the credential issues from a source I trust? (b) Has the credential expired? (c) Has the credential been revoked?  Once the validity of the credential is satisfied, the Broker authenticates the Subject by verifying the Subject can prove association to the asserted identity in the credential. Once this is done, Subject A receives a token with proof-of-authentication
2) Subject A presents the token to Broker B; Given that Broker B trusts tokens issued by Broker A, Broker B issues token to Subject A that is valid in Trust Domain B
3) Subject A attempts to access the Resource B and presents the token from the Broker B
4) Resource B validates the Subject A’s token

Once Authenticated, the resource should then verify the identity has authorized access to the requested resource, based on existing security policy.

AuthN_Brokered_I_CD_small

 

Authentication – Brokered II (Cross-Domain/Federated)

  • Clear separation of security boundaries.
  • Resource B accepts identity information from external sources but “outsources” the actual authentication to Broker B.
  • Trust between Broker B and Broker A is mediated by a third party (Bridge) which is set up before-hand and out-of-band.

1) Subject A presents a credential to the Broker A. Broker A, prior to authenticating the claimed identity presented in the credential, checks the validity of the credential. This could include: (a) Is the credential issues from a source I trust? (b) Has the credential expired? (c) Has the credential been revoked?  Once the validity of the credential is satisfied, the Broker authenticates the Subject by verifying the Subject can prove association to the asserted identity in the credential. Once this is done, Subject A receives a token with proof-of-authentication
--- Variation: Subject A has been issued credentials
2) Subject A attempts to access Resource B and presents the issued credentials (or token from Broker A)
3) Resource B externalizes the validation of Subject A’s credential or token to Broker B
4) Broker B validates credentials or token with the Bridge (Path Validation + Revocation for PKI or other mechanism with a Federation Operator)

Once Authenticated, the resource should then verify the identity has authorized access to the requested resource, based on existing security policy.

AuthN_Brokered_II_CD_small

As noted above, this is Authentication only. Comments are very welcome and would be appreciated.

UPDATE (10/16/2010): Updated post language based on comments and feedback from Russ Reopell


Tags:: Architecture | Security
9/19/2010 3:16 PM Eastern Daylight Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.