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-securitypolicy-1.0.pdf)
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.
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:
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.