Shibboleth Developers

["Scott Cantor" <>]

> Right, the alias change can be planned well for transition, great.
> Allow me to shift the focus a little to the headernames (that are now
> actually what used to be the alias, which I think is a good thing):

If you mean that I shortened the default header names and they happen to
look more like the old alias values looked, yes, that's true, but I wasn't
trying to replace one with the other...they simply are whatever you need
them to be. The defaults are just defaults I chose.

> ...and then there are the people that consume the headers 'somewhere' in
> their code. So either the admin changes the config so everything looks
> *exactly* the same in 2.0 as it was in 1.3 -and thus will unfortunately
> always stay like that-, or the application devs need to check all their
> code, and update the live app at the same time their Shib config is
> updated to Shib2.0 best practices...

I have no interest in dictating header names. There are no best practices
here. This is not like an API. It is an example file (as was the old AAP
file) that should be changed to suit developer needs. I never intended that
the names I picked be somehow "preferred".

You're right that ultimately you end up picking some and never changing
them. That's fine. There's no reason to change them, it would be
gratuitious. (The environment option requires code changes on anything other
than maybe Cold Fusion and Java apps, and that's a decision people can make
based on how safe they feel, really.)

The reason I changed the header names was just because I thought the old
names were dumb, and with the environment option, the names wouldn't match
anyway, so I figured now was the time. If people think I should just use the
same default names I used in 1.3, I am fine with that. I could also provide
another example map file that used the old names. I really don't care much
about this question.

Here's an illustration of why I changed it:

The old file had "Shib-EP-Entitlement" and this became
HTTP_SHIB_EP_ENTITLEMENT in the apps and "entitlement" in .htaccess.

The new file has "entitlement" and this would be "entitlement" in .htaccess
files, and would be either "entitlement" or "HTTP_ENTITLEMENT" depending on
whether it's Apache, and whether the environment option is left on.

So what I did was try and sort of maximize the commonality in the Apache
case. I can see the argument for going back and just saying it's
better/simpler to say "you might have to change the htaccess file but just
leave your app alone if you don't switch to environment variables".

I guess the point here is:

- I didn't spend any serious time on the defaults yet.
- Whatever people think is simplest for upgrades is fine by me.
- I think I can add back an Apache command to create the require alias and
just switch back to Shib-EP-Entitlement and maybe that's the best option.

> But in that way all of them would need a separate
> test-environment to adapt piece-by-piece.

Do you mean that it would be difficult to change them, since you'd have to
change the configuration and the code at the same time?

> Being able to map one attribute to two variables (one being the new
> environment variable, and the other being the old header, or even both
> being both env var and header at the same time) would provide a transition
> environment. I think the current code doesn't support that. It may be a
> trivial extension that could solve both the alias issue and provide
> transition environments now and in the future.

I think I'm coming around to your argument for splitting the option so that
a given id can map to both an environment variable (on Apache at least) and
a header at the same time. That doesn't duplicate anything in the cache, but
gives you simpler migration to that feature for apps, since they just change
at will. There's some extra load during each request but that's a choice
people could make.

I'm much less comfortable with multiple ids as it may complicate the code
quite a bit. I'll have to think about it and see if it's possible without a
lot of changes. I don't think it's acceptable to just create multiple
attribute objects internally and duplicate the data, if I can't do it
properly I shouldn't do it.

-- Scott