rwgorrel at uncg.edu
Wed Aug 19 17:22:13 EDT 2015
We decided on a hard line approach and have gone after your ideal only
integrating using SAML and shibb. It's been bumpy but where we're at today
with modern authentication is not so bad despite its preview status and
having to deploy registry keys in order to enable it.
On Aug 19, 2015 5:10 PM, "Aaron Howell" <aaron.howell at deakin.edu.au> wrote:
> All I can say is having SSL offloading has allowed us to work around this
> particular cookie issue and another bug that still exists with ADFSv3 -
> that Microsoft of course claim is by design. SLL Offloading at least has
> allowed us to control the requests - its also simpler as it is one location
> to update the public SSL Certificate - ADFS autoupdates from the AD
> Certificate services
> I'm not sure of how else we could have solved it (with ADFSv2 you could
> hack the aspx files, but that is the past). Maybe you can get a local IIS
> to be a proxy and manipulate the cookies/request there. But as far as I
> know there are not options in ADFS itself to affect the process.
> > On 20 Aug 2015, at 6:29 AM, Misagh Moayyed <mmoayyed at unicon.net> wrote:
> > Paul,
> > We have used the following guide a number of times to integrate the Idp
> > and ADFS:
> > https://technet.microsoft.com/en-us/library/gg317734(v=ws.10).aspx
> > It's not a trivial tasks, but it has worked perfectly fine. In certain
> > cases, we even had Idp authentication delegated to CAS via the shib-cas
> > authenticator plugin, and that also worked out really well. If there is a
> > spot on the wiki, I can document what we did and have you review it.
> > The only issue we ran into was that the built-in "IdP" in ADFS is Active
> > Directory, and you can't turn it off. Once you register the IdP with ADFS
> > as a claims provider, you get to see a discovery-like page with IdP and
> > Active Directory listed both. To get around it, we ended up modifying the
> > .aspx ADFS pages to make sure the IdP was chosen automatically.
> > Note that this is with ADFS2. I am told that 3 makes this sort of thing a
> > tad easier, though you do lose the option of modifying aspx files that
> > would be buried in DLLs as resources should you ever need them.
> >> -----Original Message-----
> >> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Paul B.
> >> Henson
> >> Sent: Wednesday, August 19, 2015 1:19 PM
> >> To: Shib Users <users at shibboleth.net>
> >> Subject: ADFS integration
> >> So we are in the same boat as I assume many other people reliant on
> >> Microsoft services are, with both a shibboleth idp and an ADFS
> > deployment.
> >> The powers that be are unhappy that they have to sign in separately to
> >> Office 365 etc, and want to integrate/consolidate authentication for all
> >> of our single sign-on applications.
> >> In an ideal world, that would mean switching all of the proprietary
> >> Microsoft services to use our nice open standards-based and freely
> >> available shibboleth deployment. Unfortunately, although Microsoft has
> >> "improved" their ability to use a shibboleth idp to authenticate their
> >> online services, according to our Windows guys it is not officially
> >> "supported", and they refuse to do it.
> >> That leaves us with somehow trying to integrate our shibboleth idp and
> > our
> >> ADFS deployment. One of our application guys pointed out some work that
> >> Unicon has done in that department:
> >> https://github.com/Unicon/cas-adfs-integration/wiki
> >> That's not going to work for a number of reasons; from a design
> >> perspective, there is absolutely no way I'm going to have all of our
> > non-
> >> Microsoft services reliant on Microsoft proprietary ADFS, which is how
> > the
> >> first option (delegating CAS authentication to ADFS) works. The second
> >> option (delegating ADFS to CAS) would be more promising, except it
> >> requires clearpass to be enabled on the CAS server, which I don't want
> > to
> >> do. And finally, we are tentatively planning on migrating our CAS
> > clients
> >> to idpv3 when we upgrade, and neither of those would work in that
> > scenario
> >> anyway.
> >> One of our Windows guys pointed out:
> >> https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop
> >> It sounds like this would allow an end-user to hit ADFS, then
> > authenticate
> >> against a shibboleth idp, and continue on to access the ADFS
> > authenticated
> >> application without explicitly authenticating to ADFS, which is exactly
> >> what I would want. However, it seems there is some extra interactivity
> > in
> >> the process, where the user must select on the ADFS landing page that
> > they
> >> want to authenticate to shibboleth instead of ADFS? And to avoid that,
> > you
> >> would need to use an SSL offloading load balancer which injects cookies
> >> into the request? We don't currently do SSL offloading, and would prefer
> >> not to.
> >> So, are there any other methods of achieving ADFS/shibboleth integration
> >> that we haven't happened upon? Is there any way when using the wiki
> > method
> >> to make ADFS automatically delegate authentication to the shibboleth IDP
> >> without munging cookies in transit? Via preferably some local IIS
> >> configuration or whatnot?
> >> Thanks much...
> >> --
> >> Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/
> >> Operating Systems and Network Analyst | henson at cpp.edu California
> > State
> >> Polytechnic University | Pomona CA 91768
> >> --
> >> To unsubscribe from this list send an email to users-
> >> unsubscribe at shibboleth.net
> > --
> > To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> Important Notice: The contents of this email are intended solely for the
> named addressee and are confidential; any unauthorised use, reproduction or
> storage of the contents is expressly prohibited. If you have received this
> email in error, please delete it and any attachments immediately and advise
> the sender by return email or telephone.
> Deakin University does not warrant that this email and any attachments are
> error or virus free.
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users