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, October 3, 2010
« Federation Flows 1 - Authentication | Main | Federation Flows 3 - Authorization »

Continuing my series of blog posts on the options available in federating identities, which I started with Authentication, I am going to try and map out some options that are available when exposing attributes.

As noted in my earlier post on Authentication, the following caveats apply:

  • 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…
Attribute Exposure – Organizational Query

  • Clear separation of security boundaries.
  • One or more authoritative sources of attributes for the Subject exist in the same Trust Domain
  • Trust relationship between Resource B and Attribute Service A set up before-hand and out-of-band

1) Subject A has been Authenticated in Trust Domain B

2) Resource B recognizes Subject A as from outside its domain and utilizes attributes from Attribute Service A

Attributes_1_small

 

Attribute Exposure – Single Point of Query 1

  • Clear separation of security boundaries.
  • One or more authoritative sources of attributes for the Subject exist in multiple Trust Domains
  • Trust relationship between Resource B and Attribute Aggregator A set up before-hand and out-of-band
  • Attribute Aggregator A has knowledge and trust relationships with attribute sources both inside and outside its trust domain

1) Subject A has been Authenticated in Trust Domain B

2) Resource B recognizes Subject A as from outside its domain and utilizes attributes from Attribute Aggregator A

3-4) Attribute Aggregator A aggregates Subject A attributes from multiple authoritative sources, wherever they may reside

Attributes-2_small

 

Attribute Exposure – Single Point of Query 2

  • Clear separation of security boundaries
  • One or more authoritative sources of attributes for the Subject exist in multiple Trust Domains
  • Resource B has outsourced attribute gathering to Attribute Aggregator B
  • Attribute Aggregator B has knowledge and trust relationships with multiple attribute sources

1) Subject A has been Authenticated in Trust Domain B

2) Resource B recognizes Subject A as from outside its domain and utilizes attributes from Attribute Aggregator B

3-4) Attribute Aggregator B aggregates Subject A attributes from multiple authoritative sources, wherever they may reside

I am most ambivalent regarding this flow because of the complexity of the moving pieces involved:

  • The multiple trust relationships that needs to be managed by the attribute aggregator
  • The attribute aggregator must “know” where all to go to get the attributes, but given that the subject is from a separate domain and the aggregator may not have a close enough relationship with the subject, would it really know where to go to get the attributes?

 

Attributes-3_small

 

Attribute Exposure – Identity Oracle
  • Clear separation of security boundaries
  • One or more authoritative sources of attributes for the Subject exist in multiple Trust Domains
  • Resource B has engaged the services of an Identity Oracle
  • Identity Oracle has close relationship with multiple Authoritative Attribute Sources

1) Subject A has been Authenticated in Trust Domain B

2) Resource B recognizes Subject A as from outside its domain and asks appropriate question of the Identity Oracle

3-4) Identity Oracle obtains relevant Subject A attributes from multiple authoritative sources and answers the question


Attributes-4_small

I am being very careful of word choices here because this is at the conceptual level and not at the implementation level.  For example, I am particular about using the word “utilizes attributes from …” rather than “requests attributes from …” so that the flows could accommodate both “front-channel” attribute passing as well as “back-channel” attribute passing. For example in the “Organizational Query” flow, the physical implementation could represent both a Federation Web SSO option that provided the attributes to the Relying Party/Service Provider as a browser based SAML Attribute Assertion or attributes requested by a PDP integrated with the Relying Party/Service Provider as a SOAP request to the Attribute Service.

Comments are welcome and would be very much appreciated.

Technorati Tags: ,,

del.icio.us Tags: ,,
Tags:: Architecture | Security
10/3/2010 8:20 PM Eastern Daylight Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.