locked
How can I specify the target URL directly in the SAML request and have AD FS 2.0 automatically redirect? RRS feed

  • Question

  • Hi all!

    I'm trying to implement SAML 2.0 Web Browser SSO using WIF (RTW) and AD FS 2.0 (RC). My scenario is strictly IdP-initiated. I have sucessfully sumbitted a SAML Response to AD FS 2.0. After a successful verification of the assertion, AD FS redirects the user to the page IdPInitiated.aspx (not 100%  sure about the name) and from what I understand, this page should display a list of relying parties to which the user has access.

    But what if I want to skip this step altogether? What if the source application already knows the target RP to which the user should be redirected? How can I modify the request (either the hidden form fields or the SAML response element) to include the ultimate target RP, and have AD FS 2.0 automatically redirect to this URL once the assertion has been verified and accepted?

    Thanks in advance!

    Sincerely,
    Daniel
    Daniel Stolt, Perceptible, http://www.perceptible.net
    Friday, January 15, 2010 12:42 PM

Answers

  • Yes, if you made your app talk SAML, you could use IdP-initiated all the way.  The only choice for automating the RP selection is to modify the IdpInitiatedSignOn page to automatically attempt to sign in - you can't send extra state from the IdP to hint at a given RP.
    • Marked as answer by Daniel Stolt Friday, January 22, 2010 11:22 AM
    Thursday, January 21, 2010 9:33 PM

All replies

  • This isn't currently possible for the IdP-initiated scenario.

    Would your scenario still work if AD FS initiated the request? The IdPInitiated.aspx page includes an ability to auto-log in to an RP if you specify the loginToRp query parameter.

    e.g.:  https://your-adfs-server/adfs/ls/IdpInitiated.aspx?loginToRp=uri:your:relying:party
    Friday, January 15, 2010 8:52 PM
  • Unfortunately, no... depending on what you mean exactly by "AD FS initiating the request" - can you clarify?

    Our scenario is to give online users of various banks and insurance companies the option of using their existing established authentication session to seamlessly transfer over to our site for additional information. The transaction is always IdP-initiated - the key is that the end user always logs on to her online bank first and then optionally continues over to our site.

    Being presented with a choice of relying party (there will always only be one allowed option: our application) upon making this transfer is not part of the plan (and could probably never be an accepted scenario for us).

    If having the RP specified as part of the request is not possible, is it possible instead to configure AD FS to always "auto-login" to the same RP in the IdP-initiated scenario - either by changing some configuration or my modifying the IdPInitiated.aspx page somehow?

    Sincerely,
    Daniel

    Daniel Stolt, Perceptible, http://www.perceptible.net
    Friday, January 15, 2010 11:08 PM
  • I think this will work.  You will need to customize the IdpInitiatedSignon.aspx.cs and HomeRealmDiscovery.aspx.cs pages.   I assume your topology is several banks acting as IPs, your AD FS acting as an FP-STS, and then your application acting as an RP?

    Each bank, in their website, would have a link to https://your-fp-sts/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=your-rp-identifier

    Out of the box, the result of clicking that link is that the IdpInitiatedSignOnPage will load and silently kick off the authentication process to your RP.  One hiccup:  if the user has never used your FP before, the user will have to navigate the Home Realm Discovery page and select the bank that they do business with.

    You could easily streamline this part of the user flow by having each bank's link be something like:  htps://your-fp-sts/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=your-rp-identifier&homeRealm=bank-identifier

    Then, before calling the SignIn function set a cookie to remember the source realm.  You will use this when calling the SelectHomeRealm function in the HomeRealmDiscovery page.

    Thus, the user's browser flow will be like:

    Visit bank.
    Click link.
    Redirected to https://your-fp-sts/adfs/ls/IdpInitiatedSignon.aspx?loginToRp=your-rp-identifier&homeRealm=bank-identifier
    FP sends SAML AuthnRequest to bank
    Bank responds to FP
    FP responds to app
    User is signed in at app

    However, from the point of view of the user, they'll just see that after clicking the link, they are now at the application.

    Does that sound about right, or have I misunderstood the scenario you're driving towards?
    Saturday, January 16, 2010 1:50 AM
  • Colin,

    You are right on the money when it comes to the overall goal. But your suggested approach involves a couple of seemingly unnecessary redirects between the organizations. The SAML profile spec allows for the AuthnRequest part to be completely omitted from the flow if the user already has an authenticated session with the IdP (this is what I thought "IdP-initiated" meant in SAML terminology). And since our scenario always starts with an already established session in one of our partner web sites (banks or insurance companies), we naturally want to take advantage of this capability of the SAML spec. Because the SAML interop test results indicated that AD FS 2.0 fully supported the IdP-initiated mode, we always assumed AD FS 2.0 would support this as well.

    Another relevant piece of background info: a federated user identity already exists between the parties, because all Swedish citizens have a unique 12-digit person number that nearly governments and organizations use to identify an individual citizen in their systems.

    Here is the flow we want to implement from the user's perspective:
    1. User logs in to an online bank website (IdP) using their proprietary authentication mechanism.
    2. IdP displays an option to jump over to our site (RP) for specialized information regarding the user's pension savings. This means a HTML form containing a hidden input named "SAMLResponse" containing a signed assertion with a subject containing the user's person number.
    3. User clicks the submit button (or the form is posted by other means).
    4. IdP posts the form with the SAML Response to https://oursite.se/adfs/ls/ containing a SAML assertion etc.
    5. ADFS verifies the assertions against our configured list of claims provider trusts.
    6. ADFS performs its claims transformation magic to shield our application from the differences in claims semantics between our various IdPs.
    7. ADFS redirects the user to our application SSO page with another set of claims that our application understands, this time using WS-Federation.
    8. Our application SSO page (configured to use WIF to accept the WS-Federation claims from ADFS) creates as authenticated session for the user, and redirects her to our main page.
    9. The user continues to use our site just as if she authenticated directly with us to begin with.

    I have tried to implement a proof-of-concept, realizing the above flow, and it works all the way up until step 7. This is where AD FS 2.0 redirects to the IdPInitiatedSignOn.aspx page, and here we are faced with two problems:
    1. The user should never have to be confronted with this page to begin with, since A) this is not a user choice and B) there really is no choice because there is only one RP to which the user should always be redirected (namely, our application).
    2. The page is empty, because it only displays RPs using the SAML protocol, and our application uses WIF and WS-Federation.

    The way I see it, I have to solve at least one of these two problems. Problem 1 is quite natural, because as it is right now, AD FS 2.0 doesn't even have a way to know which RP to redirect to. This is what I'd like to adress, and I see two potential possibilities:
    • Include the target RP in the information from the IdP, using either an additional form field, the Destination attribute of the SAML Response element, or the SAML RelayState element. This would be my preferred solution.
    • Statically configure this some way on the AD FS side of things, so that in step 7, the user is always redirected to our application (RP).

    Problem 2 is more problematic, and I have no idea how to attack it... but hopefully that won't even be necessary, if we can somehow solve problem 1 instead.

    I hope this sheds some additional light on what we are trying to accomplish, and why the extra round of redirects back to the IdP and then back to us again is excessive and something we absolutely want to avoid.

    So far, I refuse to believe that the incredibly powerful products AD FS 2.0 and WIF, built specifically for a heterogeneous claims-based identity world and with explicit and tested support for the IdP-initiated mode of the Web Browser SSO SAML profile, are not capable of realizing this seemingly standard scenario for us. Especially since it seems so easy - essentially all that needs to happen additionally is a simple automatic transfer to one of the configured RPs.

    What are your thoughts?

    Sincerely,
    Daniel



    Daniel Stolt, Perceptible, http://www.perceptible.net
    Saturday, January 16, 2010 2:18 PM
  • I am not 100% sure if I really read/understood the question properly. But it appears unnecessarily one-sided (even after second reading). If I misunderstood everything then please ignore me, I should have kept my foot in my mouth.......

    I know this is a religious topic. I'd like to remain neutral/technical. I'd like to supply the arguments that I have heard from the different camps, without choosing sides. (I must confess that my best teachers are considered/confessed opponents of IdPInitiated.....)

    - Many people want to move away from IdPInitiated because the IdP needs to know a lot (more then the oponents like) of the (final)RP (your app) and the possible path in between.
    - Some federation implementations do check where things are coming from so IdP initiated is sometimes not possible.

    If your application is written with WIF then it is WS-*. So you will have to do it the WS-* way.......
    There the traditional solution for this was (and I have to assume it still works) : redirect the user to your app at
              https://www.example.se/appname?whr=urn:federation:or:whatever
    The whr parameter contains the URI (EntityID) of the IdP (bank).
    The app will redirect to its AD FS server, which will know how to send this back to the IdP (bank) without asking the user.

    Indeed there are two extra redirects (and the implied roundtrip times), but the bank does not have to know/control how all the hops in between work.
    I'd like to see it as autodiscover/autoconfigure versus source (specified) routing....

    Paul

    P.S. Very often I am in places where I have <64 kbps and roundtrip times of 2s. So I actually would appreciate less roundtrip times :-)
    Saturday, January 16, 2010 3:56 PM
  • Paul,

    Thanks for pitching in with your thoughts! I guess you are right that a purely IdP-initiated approach potentially requires more knowledge on the IdP side. (But I think your statement "bank needs to know/control how all the hops in between work" is a bit of an overstatement; it's not about knowing or controlling how things work, it's just a matter of sending an opaque extra value along with the request.) Specifically, in addition to just knowing the target URL (our app), it also needs to know the intermediate URL where the assertions are verified (AD FS 2.0).

    However, my take on that is: When we connect a new external party as an IdP, there is a whole lot of information that needs to be communicated. This includes entity identifiers, certificates, claims and their semantics, and redirect URLs. The notion that, as part of this exchange of information, we need to give them two URLs instead of one, makes very little difference. Also, in this scenario, we don't need to know any URLs of the IdP, because we never redirect there. So, in either case, there are still two URLs being exchanged. Weigh that against the significant disadvantage of the double extra redirects, and the choice is a no-brainer in my mind.

    Now, with that said, there's also potentially the other solution I was describing, where we statically configure our app as the RP to always redirect to in step 7. In this case, the IdP still only needs to know one URL. This too would be an acceptable solution to me.

    Sincerely,
    Daniel


    Daniel Stolt, Perceptible, http://www.perceptible.net
    Saturday, January 16, 2010 4:14 PM
  • Thanks for expanding on your scenario, Daniel.

    AD FS does support IdP-initiated sign on.  Due to architectural decisions to not cache a 3rd party IP's token, you must pay the price with these extra redirects when operating in an FP-STS role.  Another wrinkle here is that IdP-initiated sign on is specific to the SAML protocol.  The WS-Federation protocol does not support this concept (however, some WS-Federation applications may "do the right thing" if they get an unexpected token response).

    All things considered, IdP-intiated sign on does not fit this particular scenario very well (FP-STS with protocol transition).  Pragmatically, your best choice to minimize roundtrips is to follow Paul's advice.  However, if your WS-Fed app will accept an unexpected response, the following series should work (step 1 is the link at the bank, steps 2-4 are automatically generated responses by AD FS and the bank):

    1. https://adfsserver.se/adfs/ls/?wa=wsignin1.0&wtrealm=https://app.se/&whr=urn:bank-ip
    2. https://bank.se/?SAMLRequest=...
    3. https://adfsserver.se/adfs/ls/?SAMLResponse=...
    4. https://app.se/?wresult=...

    The assumption is that step 1 will not show UI because whr is provided and step 2 will not show UI because the user has a sesssion at the bank.
    Monday, January 18, 2010 8:23 PM
  • Thanks for explaining further, Colin - however, I don't fully understand... far from it actually. :)

    Let me try to just spout out my questions here.

    1. Can you explain where exactly in my 9 step flow description we are going wrong? Where exactly is the problem with the steps I've outlined?
    2. You talk about caching a 3rd party IdP's token - how does this factor in to my proposed scenario?
    3. Why is protocol transition a problem? Once AD FS has verified an incoming token, shouldn't it be able to issue an outgoing token using a different protocol? I thought this was more or less the scenario that Geneva was designed for - secury the application with WIF, place AD FS in front of it, shield the application from all the differences in protocols and claims semantics between federation partners?

    Sincerely,
    Daniel
    Daniel Stolt, Perceptible, http://www.perceptible.net
    Wednesday, January 20, 2010 6:10 AM
  • 1.  In your step 7, you are at the IdpInitiatedSignOn page.  At this point, you need to sign in to the RP.  If your RP was a SAML RP, you could call the SignIn() function and do an IdP-initiated sign on (where, in this case, the "IdP" is the AD FS server).

    However, your final RP is a WS-Federation RP.  The WS-Federation protocol does not support the concept of IdP-initiated sign on.  To sign in to a WS-Federation app, the request must first come from the WS-Federation RP.  Thus, nothing is going wrong in your step 7, it's just that you can't really go anywhere from there in your particular scenario.

    2.  You can ignore this - it doesn't alter what is or is not possible, it just affects how many network roundtrips must be made.

    3.  Protocol transition is not a problem by itself.  Trying to do IdP-initiated to a WS-Federation RP is the problem.

    AD FS shields the applications and users from differences in protocols, but it cannot create a consistent IdP-initiated sign on experience for WS-Federation apps, because it's not part of the WS-Federation protocol.  To blindly throw a token over the wall at a WS-Federation app may work, but it is not guaranteed to work.

    Thus, you need to do a WS-Federation sign on request from the RP -- wa=wsignin1.0&wtrealm=your-app&whr=your-ip.  Protocol transition will kick in at the AD FS layer, where it will construct a SAML AuthnRequest for the IP -- even though the original request was in WS-Federation.  The resulting SAML response will be received and converted into a WS-Federation response for the RP.

    It's a tricky scenario - I wish I had a whiteboard. :)
    Wednesday, January 20, 2010 6:49 AM
  • Colin,

    Believe it or not, I actually think I understand it all perfectly now! :) Thank you!

    I'm trying to think of possible solutions.

    Suppose I made our application talk SAML instead, so that we could follow the IdP-initiated scenario all the way through... how would you go about automating the RP selection so the user would not have to see that page, but were instead redirected directly to our app? Could we make the IdP send something along? Or would you modify the IdPInitiatedSignOn.aspx page to do the automatic selection?

    Sincerely,
    Daniel
    Daniel Stolt, Perceptible, http://www.perceptible.net
    Thursday, January 21, 2010 4:10 PM
  • Yes, if you made your app talk SAML, you could use IdP-initiated all the way.  The only choice for automating the RP selection is to modify the IdpInitiatedSignOn page to automatically attempt to sign in - you can't send extra state from the IdP to hint at a given RP.
    • Marked as answer by Daniel Stolt Friday, January 22, 2010 11:22 AM
    Thursday, January 21, 2010 9:33 PM
  • Got it. Thank you so much for taking the time to walk me through this - much appreciated!
    Daniel Stolt, Perceptible, http://www.perceptible.net
    Friday, January 22, 2010 11:23 AM
  • Hey Daniel,

    Glad I found this thread - I just posed a similar question though less detailed than yours...I am trying to get IDPInitiated SSO working as well.

    Where did you end up exactly? Are you now using the RP initiated SSO with protocol transation as suggested above? Do you have any pointers/links to help me figure out how to so that in my case?

    I find it difficult to navigate the docs/resources out there to get the specific details I need...so any pointers/links would be great. Specicially, how to greate the CP and RP trsuts in the RP issuer ADFS and create the URL for the RP login through the external SAML based IDP...that's exactly where I am...

    Thanks in advance for your input.
    Tuesday, February 23, 2010 9:38 PM
  • Colin,

    We are using ADFS 2.0 to pass SAML assertions to salesforce.com but we want to deploy several environments (test, dev, prod etc) each having it's own unique URL but we are trying to accomplish this by having only one relying party trust defined.  If I have several different endpoints defined and add an index to them am I able to call them thru the logintorp=

    Something like this

    Dev Environment

    https://ourserver.ourcompany.com/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://saml.salesforce.com&index=0

    Test Environment

    https://ourserver.ourcompany.com/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://saml.salesforce.com&index=1

    Thank you in advance for any assitance.

    Monday, April 19, 2010 8:58 PM
  • Colin,

    We are using ADFS 2.0 to pass SAML assertions to salesforce.com but we want to deploy several environments (test, dev, prod etc) each having it's own unique URL but we are trying to accomplish this by having only one relying party trust defined.  If I have several different endpoints software defined and add an index to them am I able to call them thru the logintorp=

    Something like this

    Dev Environment

    https://ourserver.ourcompany.com/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://saml.salesforce.com &index=0

    Test Environment

    https://ourserver.ourcompany.com/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://saml.salesforce.com&index=1

    Thank you in advance for any assitance.


    Have you got the solution? I have been focusing on this thread for a long time.
    Thursday, July 1, 2010 11:25 AM
  • Since there is people that are dealing with IDP initiated sign on. I allow me to draw your attention on my problem :

    http://social.msdn.microsoft.com/Forums/en/Geneva/thread/cd6a72cd-e181-494c-a204-339bbb4c935c

     

    Thanks.

    Thursday, August 12, 2010 12:51 PM
  • Hello,

    Our company is facing this exact same problem.  Our customer wants to send SAML tokens in an Idp-initiated scenario and they will give us the destination URL in the RelayState.  But in other forums we find that AD FS 2.0 does not support RelayState in Idp-initiated scenarios:

     http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/91812934-e620-44c7-b4ef-8383083dc3c4

    The above link also describes a cumbersome workaround to get around this problem.   It sure would be nice if AD FS 2.0 supported this out of the box.

     However, this is part of the SAML spec:

    http://saml.xml.org/wiki/idp-initiated-single-sign-on-post-binding

    So why doesn't Microsoft support this?

    Daniel, can you please share what your final solution for this problem was?

    Thank you,

    Mark Horvath

     

     

    Friday, September 3, 2010 10:21 PM
  • Hello aconant, Mark Horvath and others,

    The implementation project for this was temporarily descoped on a business level, so up until now we have not worked further on this problem.

    We are back in business now however, and as it looks now, the only sensible way forwand that we can see is to build the SAML protocol support into our SP application ourselves (probably utilizing WIF to parse the tokens). The out-of-box SP functionality that WIF provides is limited to the WS-Federation protocol, and this protocol does not really support the IdP-initiated scenario (as explained above).

    Once we've done this ADFS could theoretically be used as a gateway and the IdP-initiated scenario should work (because no protocol transition needs to occur) but we are still left with the problem that ADFS does not handle RelayState to automate SP selection.

    Given that, the benefit of ADFS is greatly diminished; as a mere claims transformation engine it doesn't provide much value in our scenario since the IdPs with which we integrate are few, well known and subject to meticulous intra-organization planning and preparations. Whatever differences in token contents are still necessary we can easily handle in SP application code.

    Our current thinking is therefore to not use ADFS at all. If at some point in the future we should see more value in having an external claims transformation engine, we could easily reintroduce ADFS into the picture since we will already have done the necessary work to support the SAML protocol end-to-end.

    Hope this helps (but I expect it doesn't).


    Daniel Stolt, Perceptible, http://www.perceptible.net
    Sunday, September 5, 2010 11:00 AM
  • Hi Colin

    I've been going through these forums and cannot find a straight answer to the RelayState question. Within Salesforce.com they have support for SSO and has a feature called My Domains to assist with this. The steps are:

    1. Setup My Domain - e.g. https://abc.my.salesforce.com.

    2. Configure SSO for IdP login - https://adfs.abc.org/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://abc.my.salesforce.com

    Now - interestingly enough, when you go to https://abc.my.salesforce.com it redirects properly to adfs.abc.org, gets token, then redirects back to https://abc.my.salesforce.com.

    All this works nicely, but does not work for deep linking - e.g. if I start the request with https://abc.my.salesforce.com/00o/o. When this is done, the POST back to ADFS just has the auto-login, but with that request there is a RelayState=/00o/o in the Referer.

    Is there any possible way, through custom code or whatever, to have this RelayState reflected back after the token is issued?

    Deep Linking SSO is an extremely important component to user adoption of any system nowadays, so I am trying to figure out how to make this scenario work.

    I did try to manually force the RelayState like this - https://adfs.abc.org/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://abc.my.salesforce.com&RelayState=/00o/o but the RelayState did not get reflected.

    Any insight as to how we can make this work would be appreciated.

    Chris

    Friday, December 3, 2010 4:01 PM
  • Daniel,

     

    Boy, am I glad I ran into this thread while googling the exact scenario (steps 1-9) you described. I think I totally get the insight provided by Colin [where a true Idp initiated request into a SP (via ADFS) is redone as Idp directly links to SP, and SP (because its has no established session the first time) would end up doing a redirect back into ADFS for auth, which inturn (thru home realm disc) handshakes the claims with Idp and relays them back to SP.. Yea, a pile of redirects, and a happily logged in end user].

    My RP is SAML2.0 enabled like my Idp, but are brokered/federated using ADFS2.  I get the annoying "RP" selection page (step 7?), which obviously is unacceptable to business (bad user experience). We will have around 20+ RP's in ADFS. So, user shouldn't care what to pick. As a Idp, I know exactly where to send the user to (based on the link they clicked, which is a RP hosted site).

    I tried passing loginToRP etc to /adfs/ls as parameter, thinking it would pass it on to IdpInitiated.aspx, which can then auto-redirect user to landing page on RP.. No luck!

    If someone found a solution/patch/or a nice workaround, please post it here. Your help is sincerely appreciated.

     

    Daniel, again great work explaining in detail the scenario. You hit it the nail right on its head.

    Thursday, March 3, 2011 7:55 PM
  • Can I just say this thread has being extremely helpful in helping me with IDP initiated sign on.

    More to come later.

    Friday, March 4, 2011 9:10 AM
  • Bumping this thread. Has anyone been able to pass relay state data or a target url after SAML authenication completes? In my case my ADFS server (idp) is passing the SAML token to my relying party, it's being authenicated but then I get a blank IE page (page cannot be displayed). My RP contact tells me I need to pass the relay state or traget url information as part of my idp initiated SSO. I've tried changing the SSO link using various parameters but no joy. Also found an unsupported workaround which involes modifying the sign in pages - messy and I haven't got it to work. Anyone have a solution on this yet?
    Monday, March 14, 2011 12:24 PM
  • Hi Colin

    This may be the old forum but I am having trouble to directly log in to IDP bypassing ADFS2.0 signin screen. I tried this https://your-adfs-server/adfs/ls/IdpInitiated.aspx?loginToRp=uri:your:relying:party
    But it still takes me to signin page to pick. I want to bypass that. Are there any specific steps where and how  to change in order for this to work.

    I looked online but couldn't fine any correct answer.

    Apprecite your answer and help

     

    Thanks

    Teddy

    Monday, August 1, 2011 1:46 PM
  • The Wiki entry at http://social.technet.microsoft.com/wiki/contents/articles/3338.aspx describes possible steps to modify the ADFS web pages as a workaround to add this - but consuming the RelayState during IDP-initiated sign-on will probably not be officially supported in the current ADFS implementation (ADFS 2.0).

    AD FS 2.0: How to Consume RelayState to Automate Access to Relying Parties During IDP-Initiated Sign-On

     

    AD FS 2.0, out of the box, will consume SAML 2.0 RelayState from a Claims Provider (CP) and pass it on to a Relying Party (RP). AD FS 2.0 does not, however, make use of SAML 2.0 RelayState during IDP-initiated sign-on and RP discovery is a manual process via a drop-down menu displayed on idpinitiatedsignon.aspx. The purpose of this article is to describe modifications you can make to AD FS 2.0 which will cause AD FS 2.0 to consume a RelayState value from the IDP during IDP-initiated sign-on which will be utilized to automate access to the target RP.

    Friday, September 30, 2011 8:56 AM
  • it is possible to use ADFS and its home realm selector with ACS, where the selection made at ADFS is communicated to the ACS which does NOT (therefore) presents its own home realm selector?
    Wednesday, October 19, 2011 11:57 PM
  • Not familiar with ACS to that degree, but check http://social.technet.microsoft.com/wiki/contents/articles/2424.aspx for a different approach.

    Windows Identity Foundation (WIF): How to Utilize the WS-Federation WHR Parameter to Bypass Home Realm Discovery (HRD)

    Wednesday, November 23, 2011 8:57 AM
  • I have an issue where our internal RP would like to use one or the other Claims Provider (IDps) we have setup without having to select on the Home Realm Dicovery.

    Basically like to implement equivalant of whr in WIF but usine SAMP-P from a JAVA application.

    You could easily streamline this part of the user flow by having each bank's link be something like:  htps://your-fp-sts/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=your-rp-identifier&homeRealm=bank-identifier

    Then, before calling the SigIn function set a cookie to remember the source realm.  You will use this when calling the SelectHomeRealm function in the HomeRealmDiscovery page.

    Your steps mentioned seem promising but not sure if that is the same as what I would like to do.

    Hope you can help



    • Edited by hitmis Wednesday, January 16, 2013 6:40 PM
    Tuesday, January 15, 2013 2:38 AM
  • Hello hitmis, Have you got a solution for this issue? I'm also having same problem.

    Experts, Can you offer your help for my problem.

    I have Custom Passive STS devloped using WIF SDK added as CP to ADFS

    FP: ADFS 2.0 server

    Relying party : SAML 2.0 RP

    I'm trying to use https://your-fp-sts/adfs/ls/IdpInitiatedSignon.aspx?loginToRp=your-rp-identifier&homeRealm=Custom STS to automate the home realm discovery process but it seems like ADFS is ignoring the homeRealm parameter and always taking me to the home realm discovery page and forcing me to choose the CP from the dropdown.

    Any Thoughts.

    Wednesday, February 20, 2013 3:33 AM
  • Hello hitmis, Have you got a solution for this issue? I'm also having same problem.

    Experts, Can you offer your help for my problem.

    I have Custom Passive STS devloped using WIF SDK added as CP to ADFS

    FP: ADFS 2.0 server

    Relying party : SAML 2.0 RP

    I'm trying to use https://your-fp-sts/adfs/ls/IdpInitiatedSignon.aspx?loginToRp=your-rp-identifier&homeRealm=Custom STS to automate the home realm discovery process but it seems like ADFS is ignoring the homeRealm parameter and always taking me to the home realm discovery page and forcing me to choose the CP from the dropdown.

    Any Thoughts.


    You should use the &whr=<custom sts URI> parameter instead of the homerealm.

    Find me on linkedin: http://nl.linkedin.com/in/tranet

    Wednesday, February 20, 2013 7:37 AM
  • I have used whr parameter to call the Custom STS but getting following error

    Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> System.InvalidOperationException: MSIS7000: The sign in request is not compliant to the WS-Federation language for web browser clients or the SAML 2.0 protocol WebSSO profile

    I heard from Microsoft engineer that whr is supported only for WIF based RP  not for SAML based RP.

    Have you had similar federation setup that worked with whr parameter?

    Thanks.

    Wednesday, February 20, 2013 3:31 PM
  • Have a look at using RelayState support introduced in AD FS 2.0 RU2... example below:

    http://blog.auth360.net/2012/12/16/saml-2-0-idp-initiated-sign-on-with-relaystate-in-adfs-2-0/

    Regards,

    Mylo

    Sunday, February 24, 2013 12:48 PM