Shibboleth Login Handler questions [SEC=UNCLASSIFIED]

[Cantor, Scott]

>Second choice:
>SP --> Shib IdP (Remote User Login Handler)
>This also seems to be a dead end, as trying to get IIS to pass the
>RemoteUser to Tomcat is difficult. Even if it does get there it is likely
>to have to DOMAIN\User format, which then doesn't work very well for the
>subsequent shib LDAP lookup.

IIS should pass that automatically if it's really being set, and it's not
any trouble to do whatever you need to do in the resolver to translate
data.

That's not to say IIS + Tomcat is a great combo, it's not. But it works.

>Third choice:
>SP --> Shib IdP (Other ldP Login Handler) --> ADFS (IdP with Kerberos)
>This would work and be easy, except the Login Handler that I am after
>just doesn't exist. In the past I have successfully chained multiple ADFS
>instances together:  (SP --> ADFS-IdP --> ADFS-IdP) and it works
>perfectly.

That's because ADFS is designed to be a gateway, and is built to support
Windows' Kerberos integration, and Shibboleth is not. In turn ADFS makes a
lousy stand-alone SAML product in many respects. They both have pluses and
minuses.

>This is my first experience with the Shibboleth-IdP and it is proving to
>be much more difficult than ADFS.

I would have to ask why you don't just use ADFS then. The vendor shouldn't
be requiring specific IdP implementations, that's not the point of a
standard.

But to be blunt: you are nuts if you try to solve this by chaining
Shibboleth to ADFS. The other two options above are superior and simpler
than that will be.

-- Scott