SungHoon_Kim

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.

https://www.partner.lab/affwebservices/public/saml2authnrequest?ProviderID=http://www.sso.lab

 

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.

FWSTrace.log

[06/16/2016][00:07:41][4528][4224][1923ca15-462c7640-37751807-272dc88e-721b5c36-1cc][AuthnRequest.java][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][AuthnRequest.java][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

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

</AuthnRequest>

 

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

https://www.sso.lab/affwebservices/public/saml2sso?SPID=http://www.partner.lab

 

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.

https://www.partner.lab/affwebservices/public/saml2authnrequest?ProviderID=http://www.sso.lab&RelayState=https://www.partner.lab/another_target/

 

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.

SAMLResponse

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

    <Status>

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

    </Status>

    <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="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="#_0ecfa63f835cd2e920483a48ecfb1106d494">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>FQh0IfY30pYDbEPMx3yenPCMhnA=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>

L/1vWEw/JKp/hF+60LnAK7bLRqUzPtFG83DAkM3cpNkcoI8MWDGKLjp0+HyX5d0kO5I24fuGcuVc

ceqYjepgChAZXSBJcRuuoZPisdqRciIrV5LFiuKy3hFhHZUYH4IZ2TovhC7+yw1YbBsxQNLap6Ch

v3JaivwKa3kF5FWRWAtQarLZr2p/rHsJ0WAahsHpR3YtnP+4I513+arB/XpABnxHKAfB3JbC4Tdf

T+RF8SUQVBOMt4WiZcJHE/WSh9c28QB0WYYsAraQlTTioNDQlvuB0XfuYo19XxIYTUn1lPCqeOpH

NaXAZL/kUZe5cPtaiv88pRkmCc5h45SvOS0YyA==

</ds:SignatureValue>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>

MIIE+jCCA+KgAwIBAgIKMCdtjgAAAAAACDANBgkqhkiG9w0BAQsFADA+MRMwEQYKCZImiZPyLGQB

GRYDbGFiMRMwEQYKCZImiZPyLGQBGRYDc3NvMRIwEAYDVQQDEwlURVNUTEFCQ0EwHhcNMTYwNjE0

MDkxOTA1WhcNMTgwNjE0MDkxOTA1WjAqMQwwCgYDVQQKEwNJRFAxDDAKBgNVBAsTA0lEUDEMMAoG

A1UEAxMDSURQMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArW7xhxeky328I7tDPI74

nTzU7mFqGx/Qg7LUm5Mde7jFSAIQvkCiXYshkNlSoehjmNtMc6+mAxk5UX8FWsJRc8m2MmsdTGsV

a6nZIge0Yko38fVrAZeCAfgWj1/CFaEAxrQVUSsZ4WpYiQbtQRvfBoGzQWzti+6gl1VnMuSEzBTM

FzSNrNb4BqwaEzapL6OHnK8vnmC+AKrpOXhM64iSa9jm++4dk54/BPxfE4wfFDJDa1S9aSDlQbk+

e/PTLh7gczQnNJDBFd/IjAHwxYT12gPkFh4q8E4c2OsdzTQIbvDQOaSFZH7b5sto466XtBqniSlJ

icz63yg2Fg8yPJaV+QIDAQABo4ICDDCCAggwDgYDVR0PAQH/BAQDAgWgMB0GA1UdDgQWBBRm74Cx

uTxaDKx82siNUpnkB0nmeDAfBgNVHSMEGDAWgBSFZxTPH0bC82lcJI7RaOZdZOzPbDCBwwYDVR0f

BIG7MIG4MIG1oIGyoIGvhoGsbGRhcDovLy9DTj1URVNUTEFCQ0EsQ049VEVTVE1DMSxDTj1DRFAs

Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE

Qz1zc28sREM9bGFiP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j

UkxEaXN0cmlidXRpb25Qb2ludDCBtwYIKwYBBQUHAQEEgaowgacwgaQGCCsGAQUFBzAChoGXbGRh

cDovLy9DTj1URVNUTEFCQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl

cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9c3NvLERDPWxhYj9jQUNlcnRpZmljYXRlP2Jhc2U/

b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTAhBgkrBgEEAYI3FAIEFB4SAFcAZQBi

AFMAZQByAHYAZQByMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBCwUAA4IBAQAYCTC+

nfMTYom2H6ckQBzs89Lmt/tgfI5Y26iCFOyUAR60TfL4Nve5fzlfppn0Th1YfkFheq6wts9EJAJo

WQwpUPD8k4kyG1x/AS40Mr2P+rDQITD93Tucd6sQ1vaR3a7GiL7YlX4p7XecJu84uXMuylMDgX1n

vllzMOXN2pn9DZvfn/KNK2rk0p7TT8P/PmpCCFZWQz/IaMWcdXalceBDawIEGJD0OFRTO9w3bqGv

ed9NGYrJ+XGXpWYecRyQerAB5AUo/5R5x3Dba5W2Uu6o1d9UvSC9EzXePKOm4UbwTWxfvapoCcBt

piIYtSCrko+d01+LgZgQ+gGVjEJMWRUR

</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

        <ns2:Subject>

            <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:SubjectConfirmation>

        </ns2:Subject>

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

            <ns2:AudienceRestriction>

                <ns2:Audience>http://www.partner.lab</ns2:Audience>

            </ns2:AudienceRestriction>

        </ns2:Conditions>

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

            <ns2:AuthnContext>

                <ns2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</ns2:AuthnContextClassRef>

            </ns2:AuthnContext>

        </ns2:AuthnStatement>

    </ns2:Assertion>

</Response>

 

 

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.

Outcomes