Federation Flows 2 - Attribute Exposure

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

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

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?

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

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.