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 10, 2010
« Federation Flows 2 – Attribute Exposure | Main | Federal ICAM Support for Identity Federa... »

After the blog posts on Authentication and Attribute Exposure options in the federation of identities, this post is going to focus on putting it all together for authorization.  The caveats noted in the earlier posts apply here as well.

Authorization – Front Channel Attribute Based Access Control

  • Clear separation of security boundaries
  • Clear separation between Authentication and Authorization
  • Resource B needs attributes of Subject A to make access control decision
  • Resource B accepts Subject A mediating attribute delivery from authoritative sources to Resource B

1) Subject A’s attributes are gathered as part of the cross-domain brokered authentication Flows

2) Subject A’s attributes are presented as part of one of the cross-domain brokered authentication flows

3) PDP B makes an access control decision based on attributes that have been gathered and presented

  • While Broker A and Attribute Service A are logically separate, physical implementation may combine them.
  • While PDP B is logically separate from Resource B, logical implementation may be as an externalized PEP or Internalized Code

An example of this is an IdP or SP initiated Web Browser SSO in which the subject authenticates to an IdP in its own domain and is redirected to the SP. The redirect session contains both an authentication assertion and an attribute assertion. The SP validates the authentication assertion and a PEP/PDP integrated with the SP utilizes the attributes in the attribute assertion to make an access control decision. This, with minor variations, also supports user centric flows using information cards etc.

AuthZ_FC_small
  AuthZ_FC_2_small

 

Authorization – Back Channel Attribute Based Access Control

  • Clear separation of security boundaries
  • Clear separation between Authentication and Authorization
  • Resource B needs attributes of Subject A to make access control decision
  • Resource B is requires delivery of Subject A attributes directly from authoritative sources

Subject A’s is authenticated using one of the cross-domain brokered authentication Flows

1) Subject A’s access control decision has been externalized to PDP B

2) PDP B makes pulls attributes directly from authoritative sources and an access control decision based on attributes that have been gathered

  • While Broker A and Attribute Service A are logically separate, physical implementation may combine them.
  • While PDP B is logically separate from Resource B, logical implementation may be as an externalized PEP or Internalized Code

An example of this flow is a Subject who authenticates in its own domain using an IdP or SP initiated Web Browser SSO or a subject who authenticates using an X.509 based Smart Card to the Resource. Once the subject has been validated, the access control decision is delegated to a PDP which pulls the attributes of the subject directly from authoritative sources using one of the supported Attribute Exposure Flows.

AuthZ_BC_small

AuthZ_BC_2_small

Provided the infrastructure exists, there is nothing stopping you from using a combination of both Front Channel and Back Channel mechanisms for ABAC. For example, you may want to have the option of the Subject mediating privacy related attribute release via the Front Channel and combine that with Enterprise or Community of Interest Type attributes pulled via the Back Channel mechanisms.


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