Re: [OGSA-AUTHZ] [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007
Nate, 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. Regards, Blair ________________________________ From: Nate Klingenstein [ndk@internet2.edu] Sent: Thursday, March 08, 2007 3:39 PM To: Blair Dillaway Cc: Alan Sill; Hiro Kishimoto; OGSA AUTHZ WG; ogsa-wg; OGSA Authentication WG BoF Subject: Re: [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007 Blair & Andrew, I'm not sure the former -- having authorities describe what they're authoritative for -- is entirely desirable or practical. When we discuss "authoritative for xyz data" in the context of identity information, I think it's necessary to append "for person abc" for it to have much meaning. My IdP isn't your IdP, the same attribute may be expressed by multiple authorities, and my release policies are likely to vary by SP, so this appendix adds a great deal of complexity. For each SP to manage and interpret the matrix of attributes/authorizations/identifiers and authorities for every principal they deal with strikes me as unreasonable and unnecessarily compromising of privacy. This gets back to my core philosophy: the IdP should push everything it can, and for what it can't push(e.g. things it's not authoritative for), it should push the information needed to retrieve the additional attributes/authorizations, ideally via a discovery service associated with that user. The discovery service can dynamically handle the user/authority/request pile and collect either raw data or pointers as appropriate. If someday there's an intelligent client, then it can manage attribute and authorization locations for a principal internally, which is even better. That said, I do think conversely there's value in SP's advertising the attributes or authorizations they need in order to reduce the need for callback queries, as those requirements are likely to be relatively static and unlikely to vary by IdP or user. There are additional questions to consider when talking about attribute metadata, though. Does some third party, e.g. a federation or a CA, need to vouch for my IdP's claim that it's able to assert staff@microsoft.com<mailto:staff@microsoft.com>? Will that third party be universally trusted by all the SP's I deal with? The SP retains, and will always have, the right to validate and interpret information it receives. I believe it's the job of the authorities, intermediaries, and flows to preserve as much of that information as is practical so the SP has the basis for a decision once the information arrives. Whether the SP would like to rely on the certification of an external authority or its own judgment, it's able to do so. Any standard should recognize both sides of this coin. Anyway, regardless of your own beliefs, the expression of both attribute expression and request is possible today by using the <RequestedAttribute> and <saml:Attribute> elements from the SAML 2.0 metadata profile. Inasmuch as privileges and identifiers(NameIDFormat can be declared too, FWIW) can be thought of as attributes, I think this supports what you'd like to do, but not at the web services layer. The Higgins project seems to be trying to do this using WSDL through the IdAS API, but I don't know enough about it to talk authoritatively. ID-WSF and WS-Federation have somewhat coarse-grained abilities to express where attribute information is located as well. Does this make any sense to you? Nate. On 8 Mar 2007, at 22:40, Blair Dillaway wrote: [blaird] I see two important aspects to this. First, authorities need to be able to communicate what they are authoritative for (attributes, types of principal identities, ...) so that resource admins can know what they can rely upon in developing authZ policies. Second, resources need to be able to communicate what authenticated information they require (token types, which authorities, ...). WS-SecureConversation (http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securi...) could potentially be profiled as a way to do the latter. I'm not aware of an existing std that addresses the former.
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.
Nate, My original statement was: I see two important aspects to this. First, authorities need to be able to communicate what they are authoritative for (attributes, types of principal identities, ...) so that resource admins can know what they can rely upon in developing authZ policies. Second, resources need to be able to communicate what authenticated information they require (token types, which authorities, ...). WS-SECURITYPOLICY (not WS-SecureConversation) (http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securi...) could potentially be profiled as a way to do the latter. I'm not aware of an existing std that addresses the former. NOTE: I met WS-SecurityPolicy, and the supplied reference was to that spec. I can see why referring to WS-SecureConversation was confusing. In any event, we are talking about the first sentence in which I merely identified a problem area. Nowhere did I suggest WS-SecurityPolicy helps address this. I also did not suggest this should be solved by a protocol or that such information had to be made available on an unrestricted basis. I did suggest a standard way of representing that information would be valuable. I am interested in whether people think this is a problem worth addressing or if they believe existing approaches are adequate. If there's interest in looking at this problem, many of the issues you brought up should be considered in developing a solution. But, I don't think this thread is the place to start such a design or requirements discussion. Regards, Blair Dillaway From: Nate Klingenstein [mailto:ndk@internet2.edu] Sent: Thursday, March 08, 2007 9:07 PM To: Blair Dillaway Cc: Alan Sill; Hiro Kishimoto; OGSA AUTHZ WG; ogsa-wg; OGSA Authentication WG BoF Subject: Re: [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007 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-recommend... 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.
participants (2)
-
Blair Dillaway -
Nate Klingenstein