Anil John
Making Digital Services Secure and Trustworthy

Anil John

Federation Flows 2 - Attribute Exposure

 Tweet  Share  Share  Comment  Print  Email

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.


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