none
Relying Party showing up in idpinitiatedsignon.aspx

    Question

  • Hello,

    I was wondering if anyone could shed some light on this issue.

    When i log on to my Adfs link below https://sts.mydomain.com/adfs/ls/idpinitiatedsignon.aspx

    It showing two of my replying parties asking me sign in.

    I have up to 8 other applications i am federating but they are not showing up on this link. 

    Is this Normal? If its not, how can i remove it? Is this something my relying partner has to fix?

    thanks in advance

    Sunday, April 24, 2016 6:17 AM

Answers

  • AFAIK, as long as your Relying Party trust has a SAML Assertion Consumer Endpoint, it will show up in the list of RP available for IDP initiated logon.

    You can check if you have such endpoints in the graphical interface, or in PowerShell:

    (Get-AdfsRelyingPartyTrust -Identifier "<ID of your RP>").SamlEndpoints

    In Windows Server 2012 R2, you cannot not disclose the information. You can use a JavaScript to hide it from the users, but the info will still be available in the code (if the users are curious and look at the HTML source, they will see them). If this is acceptable for you, you can go ahead and create a custom JavaScript for that. I can provide a sample if you want to, but the info is essentially there: https://technet.microsoft.com/en-us/library/dn636121.aspx and on the Internet.

    Note that ADFS on Windows Server 2016 changed that behavior and the IdpInitiatedSignon page is not enabled by default. Although once enabled, you still need the JavaScript to hide the list or a part of the list.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Sunday, April 24, 2016 5:44 PM
    Owner
  • This is normal. The Relying Party Trusts showing up are the ones using the SAML Federation Protocol since that protocol has a 'feature' called IdP Initiated Sign On where the user can first be authenticated by your ADFS and then choose which of these Relying Party Trusts/Service Providers they want to access (by having ADFS issue them a SAML Token) and POST/Redirect the browser to that Relying Party Trust/Service Provider.

    Do note that just because a Relying Party Trust/Service Provider is listed doesn't automatically mean that they actually DO support IdP Initiated Sign In. Some Service Providers using the SAML Protocol might only accept Service Provider Initiated Sign In.

    I've hidden this list on my ADFS 2.0 Proxies for un-authenticated users (but not on our ADFS 3.0 WAPs yet).

    In ADFS 2.0 edit C:\inetpub\adfs\ls\IdpInitiatedSignOn by adding SetRpListState(null, null);

        protected void Page_Init( object sender, EventArgs e )
        {
            string rpIdentity = Context.Request.QueryString[RpIdentityQueryParameter];
    		//
            // If the query string specified a certain relying party, sign in to that relying party.
            //
            if ( !String.IsNullOrEmpty( rpIdentity ) )
            {
                string decodedIdentity = Server.UrlDecode( rpIdentity );
    
                if ( decodedIdentity == IdpAsRpIdentifier )
                {
                    decodedIdentity = String.Empty;
                }
    
                SignIn( rpIdentity, new SignOnRequestParameters() );
            }
            else
            {
                PopulateConditionalVisibilityControls();
    
                RelyingPartyDropDownList.DataSource = RelyingParties;
                RelyingPartyDropDownList.DataBind();
    
                UpdateText();
            }
    SetRpListState(null, null);
        }

    and by adding OtherRpPanel.Visible = this.IsAuthenticated;

        protected void SetRpListState( object sender, EventArgs e )
        {        
    		RelyingPartyDropDownList.Enabled = OtherRpRadioButton.Checked;
            ConsentDropDownList.Enabled = OtherRpRadioButton.Checked;
    		OtherRpPanel.Visible = this.IsAuthenticated;
        }



    Sunday, April 24, 2016 9:11 AM
  • You can't disable the page on Windows Server 2012 R2. You can hide the list in JavaScript:

    var checkidp_OtherRpPanel = document.getElementById('idp_OtherRpPanel') ;
    if ( checkidp_OtherRpPanel ) {
         checkidp_OtherRpPanel.style.display = 'none' ;
    }
    

    You'll find the guidance on how to modify the default JavaScript of the page there:


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, April 25, 2016 12:12 PM
    Owner

All replies

  • This is normal. The Relying Party Trusts showing up are the ones using the SAML Federation Protocol since that protocol has a 'feature' called IdP Initiated Sign On where the user can first be authenticated by your ADFS and then choose which of these Relying Party Trusts/Service Providers they want to access (by having ADFS issue them a SAML Token) and POST/Redirect the browser to that Relying Party Trust/Service Provider.

    Do note that just because a Relying Party Trust/Service Provider is listed doesn't automatically mean that they actually DO support IdP Initiated Sign In. Some Service Providers using the SAML Protocol might only accept Service Provider Initiated Sign In.

    I've hidden this list on my ADFS 2.0 Proxies for un-authenticated users (but not on our ADFS 3.0 WAPs yet).

    In ADFS 2.0 edit C:\inetpub\adfs\ls\IdpInitiatedSignOn by adding SetRpListState(null, null);

        protected void Page_Init( object sender, EventArgs e )
        {
            string rpIdentity = Context.Request.QueryString[RpIdentityQueryParameter];
    		//
            // If the query string specified a certain relying party, sign in to that relying party.
            //
            if ( !String.IsNullOrEmpty( rpIdentity ) )
            {
                string decodedIdentity = Server.UrlDecode( rpIdentity );
    
                if ( decodedIdentity == IdpAsRpIdentifier )
                {
                    decodedIdentity = String.Empty;
                }
    
                SignIn( rpIdentity, new SignOnRequestParameters() );
            }
            else
            {
                PopulateConditionalVisibilityControls();
    
                RelyingPartyDropDownList.DataSource = RelyingParties;
                RelyingPartyDropDownList.DataBind();
    
                UpdateText();
            }
    SetRpListState(null, null);
        }

    and by adding OtherRpPanel.Visible = this.IsAuthenticated;

        protected void SetRpListState( object sender, EventArgs e )
        {        
    		RelyingPartyDropDownList.Enabled = OtherRpRadioButton.Checked;
            ConsentDropDownList.Enabled = OtherRpRadioButton.Checked;
    		OtherRpPanel.Visible = this.IsAuthenticated;
        }



    Sunday, April 24, 2016 9:11 AM
  • Hi Moloko,

    Thanks for getting back to me so quick. I have other applications which are using Saml but not showing here. This applications are cloud based from third party and i'm also using ADFS on server 2012 R2.

    Usually, we don't use this link. Users get redirected to my ADFS server automatically when they want to access an application for authentication. I used relying partner in my first message but i should have said relying party which is just a cloud based application from a third party and not a partner.

    what makes this application showing up there different from other SAML application i am federating with? I know if i federate with partners,it will show the partner's sts when users want to access the application but i am not federating for partners to be able to login  .


    Sunday, April 24, 2016 9:53 AM
  • AFAIK, as long as your Relying Party trust has a SAML Assertion Consumer Endpoint, it will show up in the list of RP available for IDP initiated logon.

    You can check if you have such endpoints in the graphical interface, or in PowerShell:

    (Get-AdfsRelyingPartyTrust -Identifier "<ID of your RP>").SamlEndpoints

    In Windows Server 2012 R2, you cannot not disclose the information. You can use a JavaScript to hide it from the users, but the info will still be available in the code (if the users are curious and look at the HTML source, they will see them). If this is acceptable for you, you can go ahead and create a custom JavaScript for that. I can provide a sample if you want to, but the info is essentially there: https://technet.microsoft.com/en-us/library/dn636121.aspx and on the Internet.

    Note that ADFS on Windows Server 2016 changed that behavior and the IdpInitiatedSignon page is not enabled by default. Although once enabled, you still need the JavaScript to hide the list or a part of the list.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Sunday, April 24, 2016 5:44 PM
    Owner
  • Thanks both for explaining this feature. I just find it a big strange that anyone can access this page and see some of the relying party we are using. Is disabling this link is also a good idea? How can i hide this in ADFS3?



    Monday, April 25, 2016 10:01 AM
  • You can't disable the page on Windows Server 2012 R2. You can hide the list in JavaScript:

    var checkidp_OtherRpPanel = document.getElementById('idp_OtherRpPanel') ;
    if ( checkidp_OtherRpPanel ) {
         checkidp_OtherRpPanel.style.display = 'none' ;
    }
    

    You'll find the guidance on how to modify the default JavaScript of the page there:


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, April 25, 2016 12:12 PM
    Owner
  • Is it possible to specify which assertion consumer service endpoint is used when redirecting to the relying party? I tried specifying it using Relays state but it always redirects to the same endpoint albeit with the relaystate embedded. What I mean by this is that my RP has multiple ACS endpoints and I need to be redirect to specific ones rather than the same one every time e.g https://hostname1/myacsendpoint vs https://hostname2/myacsendpoint. Specifing relay state of https://hostname2/myacsdendpoint would still redirect to https://hostname1/myacsendpoint assuming that is the default specified in the RP properties.

    Jimit Ndiaye

    Wednesday, April 05, 2017 11:40 AM
  • Hello Jimit. Please create a new thread as this one is marked as answer and will not bring the expected attention.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, April 05, 2017 12:22 PM
    Owner