Anil John
Making Digital Services Secure and Trustworthy

Anil John

Federation Flows 1 - Authentication

 Tweet  Share  Share  Comment  Print  Email

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.

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

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.

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.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


Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.

Topic(s):
By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post. Please leave a comment below!

I am a digital security coach. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone