Shibboleth Developers

["Scott Cantor" <>]

> As far as I understand Scott's reply the Aliases were then later on
> added again. However, it seems they can now only be used with the
> Shibboleth 2 SP in the RequestMap, but not anymore in the Apache
> config/.htaccess file. Is this correct or is this a bug?

It would be a bug, if by that you mean that "require foo" doesn't work if
foo is defined as an alias rather than the primary attribute ID.

Note that the same code is used in the htaccess plugin vs. the XML plugin,
so I don't see yet how it could work in one place and not the other.

> Any chance that it still could be added in the first case? It certainly
> would allow an easier upgrade from 1.3 to 2.0 for a lot of applications
> that are protected with Apache access rules.

I certainly intended that it work, that was why I added it back. There
wasn't enough use of the XML option to justify adding that feature, and it
was a huge amount of work. Affected practically every API in the system
(which is why I didn't want to do it).

> Another thing we noted is that in the shibboleth2.xml.dist file there is
> the line:
> REMOTE_USER="eppn persistent-id targeted-id"
> 
> Although I couldn't find the documentation for this REMOTE_USER
> attribute

It's in the wiki. Everything is documented now with the exception of the
filtering language, which I copied from Chad's code.

> I assume that any attributes with following aliases(? or are
> these attribute IDs?) are put into the REMOTE_USER environment variable
> if they exist. If so, what happens if the eppn as well as the
> persistent-id exist as attributes?

I think for this purpose id == alias, shouldn't matter. It's just a multimap
by then, indexed by all possible names. REMOTE_USER is single valued, that's
not something to change. The list is in order of preference to use. It works
very well in practice for REMOTE_USER based apps, and gives you control
instead of just randomly ending up with one of the options.

> Besides that, we were wondering about the names of these aliases/IDs?
> Why wasn't for example principalName, persistentID or targetetID used as
> aliases? This maybe would be more consistent with other attributes,
> where the aliases usually were written withouth - and with uppercase
> letters instead. Is there any specific reason for this?

eduPersonPrincipalName was long, principalName isn't the name of anything,
and the other two are different versions of the same underlying attribute,
so following conventions doesn't really work well here. Mixed case makes
sense when the name comes from X.500, but I don't like it in practice
anyway.

-- Scott