Shibboleth SP "remote user" functionality on Windows IIS

[Cantor, Scott]

On 6/22/12 2:37 PM, "Michael A. Grady" <m-grady at illinois.edu> wrote:

>I'd like to have the functionality that the Shib SP REMOTE_USER attribute
>mapping code provides, where you can provide a list of attributes and the
>first that has a value is used. But in the IIS environment, the
>documentation "discourages" using the corresponding HTTP_REMOTE_USER
>counterpart.

If the purpose is to get that special feature, it's probably ok, but you
have to be careful with it and understand that it's just a header and is
not really REMOTE_USER. Most people are fine with doing their own
attribute consolidation work, so avoiding it is usually the best advice.

It is really just a simple line of code in a web app "include" file of
whatever sort to consolidate information and pick the first value from a
set.

> It looks like Shib SP 2.5 will offer more attribute manipulation
>options, but I'm wondering -- short of using the HTTP_REMOTE_USER option
>-- how I might replicate the "use the first of these attributes that has
>a value" for the value of a mapped attribute with the 2.4.3. version of
>the SP. It strikes me that I might be able to do this with attribute
>filtering.

I don't think there's anything in 2.5 that would simulate this feature,
exactly. Maybe the transformer would, I'd have to look at it and see what
ordering guarantee it provides.

Filtering probably wouldn't do any good. It can't create a new attribute,
and throwing away values doesn't seem like it would be the same thing.

>First, does filtering happen after mapping?

Filtering runs against each source of attributes, after the attributes
have been resolved, extracted, or whatever is involved. It runs against
the pushed attribute set after they're extracted, and it runs inside the
query and aggregation resolver plugins after they extract data from the
external source.

> Am I filtering the values in the IDs/aliases mapped into, or the
>attributes being sent by the IdP before being mapped?

The former. Filtering operates on a set of internal attributes inside the
SP, much like filtering in the IdP works  against the internal resolver
attributes before they're encoded into SAML. The SP filtering happens
after decoding from SAML.

> If the former, would a script attribute filter be able to manipulate an
>ID's value?

Filtering never changes values, only removes them. And there is no script
option. Embedding a scripting engine in a C++ application is very
non-trivial.

> If the former, I assume I could filter out the one attribute value if
>the other attribute had a value, and then there would be only value to
>map into the ID. Can one of those work?

Well, you can filter based on "number of values" of an attribute, but I
don't think you can accomplish this with it. I can't think of any obvious
way.

-- Scott