Shibboleth Developers

[Velpi <>]

[ShibUseEnvironment Off]
> I can play with it. I didn't want it to be just a server setting, since it
> affects application access to the data, ir might be different per
> application tree.

This makes a lot of sense to me too (please read on)...


> > dev-discussion about https://bugs.internet2.edu/jira/browse/SSPCPP-22 :
> > "attribute aliases not available anymore"
> > This creates a (the only I noticed so far) compatibility issue, but I
>
> It's a pretty minor one that you can fix by editing your htaccess rules when
> you upgrade, that doesn't seem all that onerous (compared to changing apps).
> For sites using the normal "or" logic, you can just add rules, in fact,
> ahead of time, with the new names. I really had no idea anybody was even
> widely using the feature, I find htaccess rules useless for real
> applications.

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):
...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...


> > The best technical solution I see:
> > * "ShibUseEnvironment On" + "ShibUseHeaders On" (default On+Off)
>
> That's separate from the alias question, but why would you want to do both,
> what would it accomplish for you that simply setting the one setting on/off
> for different content wouldn't do? I didn't expect people to immediately use
> the environment option if they have older apps, certainly. But I assumed
> people would just tweak some htaccess files and make the IDs match their old
> header names until they want to change them.
> > * being able to define an attribute twice with different ID's in the
> > attribute map (or something like that): this should solve a big pool of
> > (future) compatibility problems.
>
> Same question...what's the use case you're trying to solve, apart from the
> lack of an alias? Duplicating all the data in memory is a pretty large price
> to pay just avoid changing a file.
>  
> Note that the extraction is configured per-app, so if you had multiple
> applications and one needed one set of names and the other needed a
> different set, you can just use separate applicationIds for that, and create
> old and new attribute maps.

I'm thinking about a setup that runs a few dozen (small, maybe badly 
maintained, but regularly used) applications on one webserver. Em, 
right, it's already possible by applying either a new or an old 
attribute map to an application. But in that way all of them would need 
a separate test-environment to adapt piece-by-piece. Possible, but it 
looks somewhat cumbersome... which will probably delay upgrading for 
most people.
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.


> The main reason I don't like all this screwing around is that using the
> single ID is a really nice and important simplification for the system, both
> SP and IdP. I really don't want to lose that. I think the alias thing was
> very confusing.

I totally agree.


-- Velpi