Skip to Content.
Sympa Menu

shibboleth-dev - RE: Access Policy strawman

Subject: Shibboleth Developers

List archive

RE: Access Policy strawman


Chronological Thread 
  • From: Scott Cantor <>
  • To: 'Noah Levitt' <>
  • Cc: , ,
  • Subject: RE: Access Policy strawman
  • Date: Fri, 04 Jun 2004 12:09:24 -0400
  • Organization: The Ohio State University

> In the arp gui discussions we've been assuming that the arp
> gui can figure with some certainty out whether a user is
> going to get access to a particular resource, which demands
> all of this detail.

I know why you want to do that, but I think it's a bad idea to go into this
with that as a requirement from day one. I don't think it's obvious to us
that services would want to publish this kind of information to the world.
What if the policy is based on EPPN values, for example, as many (most?) ad
hoc smaller services might be?

It's also likely to be more dynamic than most of the other metadata, which
increases the work to keep it updated.

> In what ways is my xml insufficient to _be_ the source data?

It might be sufficient, although if you're trying to capture actual access
control policy, I think you do ultimately have to look at using XACML if
only because it has a much stronger framework for expressing complex
policies than anything we'd be likely to invent.

> Are we planning to continue using .htaccess in 1.3, or will
> that change? If it's going to change, what did you have in
> mind as a replacement?

If you mean is the use of htaccess files in Apache going to be dropped, I
can't see that being a good idea. But there is an AccessControl hook already
implemented in 1.2 that supplements htaccess (or in the case of IIS or, say,
Java, could take the place of it). I just didn't implement anything inside
it, although there's a schema for something resembling htaccess plus some
boolean operators.

It hangs off the RequestMap elements because that's how the processing model
works in the code. What you have would probably have to be implemented as an
alternate request mapping mechanism because it's too expensive to do that
work multiple times on every request to find different pieces of
configuration.

I separated the attributes to request into the Application element because
it only makes one query on behalf of all resources in the Application, and I
didn't want to have to calculate the set by combining them. I really didn't
see how that made things that much easier, especially since the AAP lets you
map the attribute names to shorter aliases that you can reference from
things like htaccess.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page