Federation Starters 4

Blog Post created by SungHoon_Kim Employee on Jun 16, 2016

This is continuation from Federation Starters 3


I will be demonstrating how to setup SP Initiated Federation.

And in this case, I will have SP to sign the AuthenRequest before sending it to IDP.

How to know if the captured fiddler is showing SP Initiated Federation? If you see "SAMLRequest" then it is SP Initiated Federation which is also called AuthnRequest.


It is initiated by accessing the following URL.



But in the current setup, because SP Initiated Federation is not configured and is not allowed, you will get HTTP 403 if you try.

FWSTrace.log explains the error as below.


[06/16/2016][00:07:41][4528][4224][1923ca15-462c7640-37751807-272dc88e-721b5c36-1cc][][processRequest][SP initiated requests are not supported for SP http://www.partner.lab.]

[06/16/2016][00:07:41][4528][4224][1923ca15-462c7640-37751807-272dc88e-721b5c36-1cc][][processRequest][Ending SAML2 AuthnRequest Service request processing with HTTP error 403]


As the federation is already setup, following are the actions I will perform to enable SP initiated federation.

SP side to sign the AuthnRequest is not required but that is additional thing I will be doing.


SP Side Configuration:

1. Import existing key pair(since we already tried generating one from AdminUI) for SP side to sign the AuthnRequest. Again, this is optional. And as federation is an agreement, IDP side need to be informed that you will be signing the AuthnRequest and provide them the certificate for them to use for signature verification.

2. Configure SP Side Partnership to allow SP Initiated Federation.

3. Configure SP Side Partnership by assigning the keypair for signing.



IDP Side Configuration:

1. Import SP signing certificate for verification

2. Configure IDP to allow SP Initiated Federation

3. Configure IDP Side Partnership to use that SP certificate to verify the signature of AuthnRequest.

4. Configure IDP to accept only signed AuthnRequest. (Optional. Even if you did not enable this, if the AuthnRequest comes in signed, IDP will try verifying the signature anyway.)


Not really much here because the federation is already setup.


Let's perform the SP side configuration first.

1. Import existing key pair

Click "Import New"

You are seeing IDP's signing key but if you had configured SP on a separate policy server then you would see IDP side certificate(not key) and the Type should be "Certificate" not "Private Key and Certificate".

Just to note so that you won't be confused.

Since you are importing a key, you will have to enter the private key's passphrase to import the key.

The alias is automatically generated and is in a format of a GUID.

I am changing it to something more meaningful. No spaces allowed so it will be "SP_Side_Key".

I didn't have to import the "TESTLABCA" RootCA certificate as it was imported previously.



2. Configure SP Side Partnership to allow SP Initiated Federation.

Deactivate the "PARTNER2SSO" partnership first and then click "Modify".

Goto "SSO and SLO" step and change the "Transactions Allowed" from "IDP initiated only" to "Both IDP and SP initiated". You can also try the "SP initiated only".


3. Configure SP Side Partnership by assigning the keypair for signing.

Goto "Signature and Encryption" step


At the "Signing Private Key Alias" select "sp_side_key".

AND YOU MUST SELECT "Sign Authentication Requests". It is easy to forget this part.


I would encourage you to try out the encryption as well, but later

As you can see here, there are lots of options for you to explore.


Finish the partnership configuration and activate it.

Let's move on to IDP side configuration.


Deactivate the "SSO2PARTNER" partnership and modify.


1. Import SP signing certificate for verification

Well, because I am configuring on one policy server, SP side certificate is actually already imported.

So, we will skip this one.


2. Configure IDP to allow SP Initiated Federation

Goto "SSO and SLO" step and change the "Transactions Allowed" from "IDP initiated only" to "


3. Configure IDP Side Partnership to use that SP certificate to verify the signature of AuthnRequest.

4. Configure IDP to accept only signed AuthnRequest.


Goto "Signature and Encryption" step and select "sp_side_key" at "Verification Certificate Alias".


Complete the setup and activate the partnership.


Another round of test, this time it will be SP initiated.

Previously we got HTTP 403 and the reason was SP initiated federation was not allowed.


As you can see above, AuthnRequest was not rejected.

And by finding a SAMLRequest query parameter at saml2sso, you would know this was an SP Initiated Federation request.


If you want to know what that SAMLRequest was, you can use fiddler to decode the content.

It would not be able to help if the AuthnRequest is encrypted but our agreement was that there is no encryption involved.

URLEncode(Base64Encode(Deflate(AuthnRequest))) is how it is generated so you need to reverse the steps to extract plan-text AuthnRequest.

Fiddler does it for you.


<AuthnRequest Destination="https://www.sso.lab/affwebservices/public/saml2sso" ID="_f868558d6f75b940077a3c738c9712adca65" IssueInstant="2016-06-16T04:48:14Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol">

    <ns1:Issuer xmlns:ns1="urn:oasis:names:tc:SAML:2.0:assertion">http://www.partner.lab</ns1:Issuer>



Basically there are 3 information.

1. Destination: This is where this message should be delivered to. Recipient must ensure that it was meant for them.

2. ID: This is the AuthnRequest ID. IDP must say "InResponseTo" and mention this ID value in the Assertion.

3. Issuer: This is the entityID that generated this AuthnRequest.


When you tried IDP initiated federation, the only information you needed was the SPID(SP's entityID).



So, AuthnRequest message delivers that information to IDP so the assertion can be generated for this partner(entityID).


Kelly raised a very interesting question.

If TARGET is not configured at the Service Provider side partnership configuration, and if RelayState is not allowed, what will happen?


I thought it would be an HTTP 500 condition but it was not.

If you do not specify the TARGET(which is acceptable), you should enable RelayState to override TARGET.

But, the moment you empty the TARGET, RelayState is accepted automatically.

However, if you do not specify the RelayState in the querystring, you do not have TARGET nor RelayState.

In this case, the result was HTTP 400 at the https://www.partner.lab/affwebservices/public/saml2assertionconsumer.


If you want to use a RelayState(deeplink) you can do it like this.



When RelayState is received at the SP side and if RelayState is allowed, the RelayState url will be stored in SMFED_TEMPORARY_STATE cookie(encrypted).


SP will again read this cookie and say "cookie contains target:https://www.partner.lab/another_target/"

"targetURL:https://www.partner.lab/another_target/ usingRelayState: true"



Now, let's take a look at SAMLResponse value and see how to extract plain-text.

Again, if it is encrypted, you will not be able to get anything out using fiddler.


In the request Body, you will find SAMLResponse but because it is very long, the name was not visible.

You can see the value is there(long base64 string).

Send it to TextWizard.

From my testing, both "From Base64" and "From DeflatedSAML" were able to decode it.

But the correct way would be simply Base64 decode only.


<Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://www.partner.lab/affwebservices/public/saml2assertionconsumer" ID="_9c1ece3b9e20f33d166dbce220ee0239ddeb" InResponseTo="_f868558d6f75b940077a3c738c9712adca65" IssueInstant="2016-06-16T04:48:34Z" Version="2.0">

    <ns1:Issuer xmlns:ns1="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.sso.lab</ns1:Issuer>


        <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>


    <ns2:Assertion xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_0ecfa63f835cd2e920483a48ecfb1106d494" IssueInstant="2016-06-16T04:48:34Z" Version="2.0">

        <ns2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.sso.lab</ns2:Issuer><ds:Signature xmlns:ds="">


<ds:CanonicalizationMethod Algorithm=""/>

<ds:SignatureMethod Algorithm=""/>

<ds:Reference URI="#_0ecfa63f835cd2e920483a48ecfb1106d494">


<ds:Transform Algorithm=""/>

<ds:Transform Algorithm=""/>


<ds:DigestMethod Algorithm=""/>










































            <ns2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user1@sso.lab</ns2:NameID>

            <ns2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

                <ns2:SubjectConfirmationData InResponseTo="_f868558d6f75b940077a3c738c9712adca65" NotOnOrAfter="2016-06-16T04:50:03Z" Recipient="https://www.partner.lab/affwebservices/public/saml2assertionconsumer"/>



        <ns2:Conditions NotBefore="2016-06-16T04:48:03Z" NotOnOrAfter="2016-06-16T04:50:03Z">





        <ns2:AuthnStatement AuthnInstant="2016-06-16T04:48:33Z" SessionIndex="0bPw0g1eWIeZSojKJjAJgkyhtfY=e1ELQw==" SessionNotOnOrAfter="2016-06-16T04:50:03Z">









Again we are seeing 3 information, same as what we saw in the AuthnRequest.

Response ID. I mentioned that it has to say InResponseTo to the AuthnRequest ID _f868558d6f75b940077a3c738c9712adca65

You can see it here in the SAMLResponse.


Also there is Issuer.

It means http://www.sso.lab is the EntityID that generated this document.


And there is Recipient.

It means this message should be sent to https://www.partner.lab/affwebservices/public/saml2assertionconsumer

Recipient must verify that it was meant for this SP.


Now that IDP and SP initiated federation is working, I will demonstrate how to setup Artifact profile.