ADFS 3.0 integration resource dll black magic

[Aaron Howell]

Another option - someone else replied to the list the other day with this gold nugget I hadn't seen before. I haven't tested it myself yet - but was planning to - we currently use the cookie. I would not go touching the DLL.

Unfortunately for this method looks like it might need to be set for every SP (Relying party) - but I was thinking a simple script could handle it and we don't have a lot hanging off of ADFS so makes it easier for us. Hope it helps.

Cheers
Aaron

https://blog.uvm.edu/jgm/2014/03/18/sharepoint-2013-adfs-shibboleth-the-motion-picture/
Part 6:  Where are you from?  Notes on Home Realm Discovery

When an ADFS server has multiple “Claims Provider Trusts” defined, the ADFS login page automatically will create a “WAYF”, or “Where are you from?” page to allow the user to select from multiple authentication providers.  In our case, the user would see “Active Directory” and “UVM Shibboleth”.  Since I would not want to confuse people with unnecessary choices, we can disable the display of one of these choices using PowerShell:

Set-AdfsRelyingPartyTrust -TargetName "SharePoint 2013" -ClaimsProviderName "UVM Shibboleth"

In this sample, “SharePoint 2013” is the name of the relying party defined in ADFS for which you want to set WAYF options.  “UVM Shibboleth” is the Claims Provider Trust that you want used.  This value can be provided as an array, but in this case we are going to provide only one value… the one authenticator that we want to use.  After configuring this change, ADFS logins coming from SharePoint get sent straight to Shibboleth for authentication.

On 18 May 2016, at 12:07 PM, Paul B. Henson <henson at cpp.edu<mailto:henson at cpp.edu>> wrote:

We are looking once again at establishing a trust relationship between our idp and ADFS. My understanding is that in order to avoid the user having to select between two authentication options after the trust relationship is established, you can either insert a load balancer/reverse proxy between the clients and the ADFS server to synthesize a cookie, or you can modify a file on the ADFS server. Unfortunately, as of ADFS 3.0 said file is tucked away inside of a resource DLL.

I was hoping someone could provide me the technical details of exactly what the name of said DLL is, the path in the file system at which it might be found, the name of the file within it that needs to be extracted, and what exactly needs to be changed in that file to accomplish the removal of this selection process and defaulting to the shibboleth idp for authentication? While I have been able to find a few sources describing the general concept of doing this, I haven't been able to find anything describing the precise details of actually doing it.

Thanks...

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu<mailto: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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160518/f9f5b8bb/attachment.html>