ADFS 3.0 integration resource dell black magic

[Lipscomb, Gary]

Another possible way is to add a cookie via the load balancer

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Aaron Howell
Sent: Wednesday, 18 May 2016 12:43
To: Shib Users <users at shibboleth.net>
Subject: Re: ADFS 3.0 integration resource dll black magic

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> 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
California State Polytechnic University  |  Pomona CA 91768


--
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.

Charles Sturt University

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia
http://www.csu.edu.au
The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795
(ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018


Consider the environment before printing this email.