[ogsa-wg] [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007

[Nate Klingenstein]

Blair,

Thanks for the elaboration; I took the association with WS- 
SecureConversation rather than WS-Policy to imply in-band and read  
"rely upon" as a firmer statement than you intended.

This time, I'll assume that by "some way for SPs to discover the IdPs  
vocabulary" you still mean a protocol of some sort to do so, which  
isn't necessarily used during the identity exchanges themselves.   
Hopefully that's not too off-base so this message will be more useful  
to you.

It seems you're talking more about awareness of what the choices are  
when writing policies, not what you're guaranteed to receive while  
executing them.  It's absolutely true that to write an access control  
policy in the first place you need to know the names, semantics, and  
probably values of authorization-related information.  Where I  
believe we differ is I don't see pre-configuring that data,  
especially in metadata, as pragmatic.  A few of my reasons:

1)  Most IdP's won't release any sensitive information to default or  
anonymous relying parties.  See, for example, the UK Federation  
Technical Guidelines, which stress repeatedly that "identity  
providers should never attempt to delegate [the] responsibility [of  
deciding which attributes to release] by relying on appropriate  
AttributeDesignator elements being expressed by a service provider."   
We've encountered many IdP's who won't send an authentication  
assertion to an unauthenticated relying party, let alone group  
information, attributes, or XACML policies.  There have to be  
agreements and understandings in place.  That means people get in the  
way of the machines by manually determining release policies and we  
have to figure out what's available for access control decisions OOB  
anyway.

http://www.ukfederation.org.uk/library/uploads/Documents/technical- 
recommendations-for-participants.pdf

2)  Entitlements and authorizations are usually defined explicitly  
for a particular service, which means the value doesn't exist a  
priori and the IdP has to populate the value for the SP.  See section  
7.1.5 of the UK Federation Technical Guidelines.  I assume this would  
be even more likely for XACML because it's such a powerful language.
3)  For custom and local data definitions, which group-based  
authorizations regularly tend to be, it'd be difficult to interpret  
the authorization schema(for lack of a better word) received,  
particularly when you just get an eduPersonEntitlement URI.
4)  There's likely to be significant push-back on publication of any  
useful authorization-related information because of privacy and  
security concerns.
5)  Most of the vendors don't support the current standards that  
allow for even primitive discovery and don't consider federations  
bigger than a bilateral contract a primary business driver.
6)  Some federations are even actively recommending *against* this  
practice -- in this instance, the use of <saml:Attribute> in metadata:

http://www.e.govt.nz/standards/e-gif/authentication/nzsams/ 
chapter12.html

All that said, I think there's great value in general attribute  
standardization out-of-band and in policy documents to the extent  
possible.  That would be a great exercise for some subset of the grid  
community to undertake.  Many federations recommend/mandate a small  
set of attributes all IdP's should/must support and describe their  
semantics(e.g. the UK and http://feide.no/dokumenter/ldap/ 
FEIDEldap.html#tth_sEc5 ).  I'm also in favor of a resolvable schema  
for defining a simple attribute, primarily for flexible maintenance  
of controlled vocabularies.

It just seems that to me that trying to represent the attributes/ 
groups/permissions an IdP could supply is not feasible today.  If you  
can think of ways to alleviate my above concerns or show how they  
aren't relevant to what you're suggesting, I'd be very interested in  
your ideas.

Really hope this is more along the lines of what you want,
Nate.

On 9 Mar 2007, at 02:40, Blair Dillaway wrote:

> I believe you mis-understood what I was trying to say. If one  
> wishes to write an attribute-based authorization policy for a  
> resource, one must know what attributes a client could provide. I  
> can't, for example decide to write a group-based authZ policy  
> unless I know some IdP(s) will tell me about what groups a client  
> is affliated with and how that group attribute is encoded. As you  
> mention there could be several different group attribute types used  
> by different IdPs. There has to be some way for SPs to discover the  
> IdPs vocabulary. This tends to be handled in various ad hoc ways  
> and can be difficult to discover and track over time. I was  
> suggesting that having a standard way of doing this for large  
> distributed systems is valuable.
>
> This is completely independent of whether client attributes are  
> pushed, pulled, sent via intermediaries, and how an SP decides  
> whether that info is trustworthy.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070309/de9e60be/attachment.html