On 27/03/18 17:07, Anwar Mahmood wrote:
> Hello,
>
> I work in the IT service delivery team at University of Central Lancashire.
>
> We have…
> • AD FS
> • Shibboleth
>
> AD FS offers integrated ("invisble") authentication; Shibboleth requires explicit authentication.
>
> We have lots of external service providers connected with Shibboleth.
> Can I...
> 1. Add Shibboleth as a relying party to AD FS.
> 2. Configure Shibboleth to use AD FS as an identity provider
>
Yes, in principle, and others have covered the details of this elsewhere
in the thread.
<snip>
> Another option is…
>
> IdPAuthRemoteUser - Shibboleth 2 - Shibboleth Wiki
> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser
>
There's not much to add here that Peter and others haven't covered, but
setting up a Shibboleth SP to protect the /idp/Authn/RemoteUser path and
using RemoteUser authentication would be the way I'd go about it, too.
I'm assuming that since you're still running IdP v2, you're probably
running this on Linux and Tomcat. It would certainly be doable using
IdP v2, but I'd upgrade to IdP v3 anyway on support grounds.
My preferred route would be to chain things the other way around, and
set up IdP v3 as a claims provider to ADFS. You could then set up the
SPNEGO and Password flows (both using the same Kerberos keytab) in the
IdP and pass the Shibboleth claims through ADFS either as-is or suitably
transformed. I think that approach is also more heavily used elsewhere
than using a Shibboleth SP/IdP pair as an ADFS RP.
> But the page doesn’t really provide a full solution.
>
> Long term, we should move service providers directly to AD FS. And we will, where possible. This is an intermediate fix.
Unless the service providers are all set up with bilateral metadata
swaps, using ADFS for this sounds painful. ADFS4 supposedly improves
the federation aspects, but still can't verify that the metadata has not
been tampered with.
--
Dr Robert Bradley
Identity and Access Management Team, IT Services, University of Oxford
|