On Mon, Sep 13, 2010 at 04:08:24PM -0400, Scott Cantor wrote:
> > Difficult... A complete set would be difficult, but only because it'd
> > be large. A useful set of "cooked" attributes (the alternative to raw)
> > should not be too difficult.
>
> What I meant by "cooked" is handling non-trivial syntax, policy-based
> filtering that relies on SAML metadata, performing queries, that kind of
> thing. If there's agreement to leave that kind of thing out of scope and
> just support a direct mapping of SAML constructs to GSS name attributes, I'm
> fine with that.
>
> The "set" though is infinite, as there are no standard attributes in SAML.
> You can't even count on URI naming, although I'm usually in favor of making
> life painful for anything else.
I know, but I was hoping there'd be a smallish (finite) set of
standardized, useful attributes, so that we could provide cooked access
to those and raw to everything.
> > What kinds of SAML attributes are we talking about anyways?
>
> Mostly the same kinds of things one finds in X.500/LDAP, but naming is a
> pain in the ass because of some vendors that won some arguments I'd like to
> go back in time and re-argue.
Ah. I was thinking too of semantics, things like "hours that user may
login" and so on, for which we could map to generic attribute syntaxes.
> Identifying users/principals is also arbitrary, and one of the standard ways
> of doing that isn't a simple string.
I'm so sorry.
> But that's all solvable. I'm just trying to work with Luke to draw the right
> functional boundaries, so I know where my code does and doesn't contribute.
Understood.
Let's consider two options: the GSS-API cooks, versus the application
cooks. In the first model you'd have to deliver plugins to the meghglue
to cook new attributes, and you'd have to modify the application only to
handle new "kinds" of attributes (new generic syntaxes). In the second
model you'd have to modify the application only. The second model will
always be feasible because we'll always provide raw attribute access.
Which model is more attractive? I think that depends on how large a set
of useful, generic syntaxes you can think of versus how many non-
generalizable, useful/used attributes exist. If the latter dwarfs the
former then I think the second model wins.
Nico
--
|