URL encoding in Forms Auth Target

[Adam Rusniak]

Hi all,

 

Wondering if anyone has run into this scenario. We are setting up a Saml 2 federated partnership. The IDP is not CA Siteminder but is a SAML compliant partner. Our SP side is a CA siteminder implementation with the Web Agent Option Pack set up for the federated servlets. 

 

My question is about protecting the resources at the Service provider side. We allow both IDP and SP initiated requests in the partnership. I have tried creating a HTML forms authentication scheme and protected the service provider resource with this auth scheme. On the auth scheme I am setting the parameter so that it invokes the SP initiated transaction with the AuthN request. Now I have this working fine in my lab with a simple IDP entity ID that doesn't require URL encoding. 

The problem is at the customer site when the entity ID is a resource like http://idp.test.com/servlet/blah this requires the URI encoding. The request works fine when you directly initiate the full SP UrL with the ProviderID=EncodedversionofEntityId

 

What I see though when setting this up as the html forms target is that it does its own encoding of the URI and the policy server is ever able to locate the IDP ID because it is not decoding the encoded portion of the URI.

 

Has anyone run into this scenario? Another maybe dumb question is, Can the SAML 2 Auth scheme template be used in a Partnership Mode or is it only valid for Legacy Federation?

 

What is the best practice for protecting against users directly accessing a resource that is set up in a partnership fed model? My plan is to protect them with our specially crafted forms auth scheme which works fine with nonencoded provider Id but not encoded.

 

 

Thank you,

Adam

[wonsa03]

Hi Adam,

 

SAML 2.0 template is only for legacy federation.

 

To overcome this, try create IDP entity with URL-encoded value as entity ID.

 

Let's say your IDP entity ID is http://idp.test.com/test. The entity ID value specified in the Partnership setup should be "http%3A%2F%2Fidp.test.com%2Ftest".

[Adam Rusniak]

Hey thank you for the reply. I will definitely try this and let you know. It was a meta data import of the IDP and I never even though of this happening.

 

Is this common to have to encode the entity ID and using the html forms scheme to initiate the transaction? 

Thank you, 

Adam

[Ujwol]

Hi Adam,

 

Did you verify who is doing the encoding of the entity ID ?

Looking at the sample use case that Kim wrote : Federation Starters 2 

His entity IDs are similar :

"http://www.sso.la" and "http://www.partner.lab

 

I don't see a need to provide an URl encoded version of entityID.

That doesn't look right to me.

 

Regards,

Ujwol

[Adam Rusniak]

Hi Ujwol,

 

So to clarify here is what I am seeing today. You are right, the Provider ID does not seem to be required to be encoded when you access the site this way:

https://testserver.us.lab.com/affwebservices/public/saml2authnrequest?ProviderID=http://testIDP.test.com/adfs/services/trust

 

 

Here is what happens when I have a Siteminder protected resource at the service provider side called headers.aspx.

The headers.aspx realm is protected with the custom Authentication scheme that we created. The parameter on the custom Authentication scheme is:

https://testserver.us.lab.com/affwebservices/public/saml2authnrequest?ProviderID=http://testIDP.test.com/adfs/services/trust 

 

The SSO Service URL configured in the partnership is: http://testIDP.test.com/adfs/services/trust

 

Hitting the headers.aspx page generates a 302 and we see the following occur: Note that the affwebservices doesn't seem to do anything disambiguating the ProviderID= into the IDP and pull the information from the partnership. We see nothing being logged in affwebservices.log or the FWSTrace.log for this transaction.

 

http://testIDP.test.com/adfs/services/trust?TYPE=33554433&REALMOID=06-4c5a6f94-7b9d-4d2b-ac40-2a98ada2c024&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=-SM-jzxX763L%2bC48ErD%2f6MVgw3rXNNGa0txSS%2br%2bj3thudEnjcTGL6%2buIsHROJM%2bKC4I&TARGET=-SM-https%3a%2f%2ftestserver%2eus%2elab%2ecom%2fheaders%2easpx

 

 

When we access the site without going through the SiteMinder forms authentication scheme by going to:

https://testserver.us.lab.com/affwebservices/public/saml2authnrequest?ProviderID=http://testIDP.test.com/adfs/services/trust

 

we properly get sent to the the IDP for authentication and the SAML transaction happens normally.

 

I can not explain why it is not working going through the forms server, I can get it to work if I create a .html page with a meta refresh redirect to the link https://testserver.us.lab.com/affwebservices/public/saml2authnrequest?ProviderID=http://testIDP.test.com/adfs/services/trust

 

and place that as custom html page as the target on the forms auth but not directly having the SAML SP initiated link as the target.

 

The strange thing is this works fine in my lab with the SP initiated link being set as the forms auth scheme target and I have no issues. The only difference in the lab is that Siteminder is both the IDP and the SP....

 

 

Any thoughts?

 

Thanks,

Adam

[Ujwol]

So the difference between the non working setup and your lab setup is , in the non working setup you are using custom authentication scheme where as in your lab you are using FORMS auth scheme ?

 

That then looks like an issue with custom auth, isn't it ?

This is not the problem with IDP not being Siteminder , as the problem is happening on the SP side of web agent.

[Adam Rusniak]

Hi Ujiwol,

 

I'm sorry I was careless with my description. I am not using a custom auth scheme in either location. Both are using the forms template. I don't know why I described it as custom only in that I don't call a traditional fcc page.

 

Both use the exact same setup on the forms schemes.

 

Thanks

Adam

[Ujwol]

Can you share the screenshot of the the nonworking auth scheme setup ?

[Adam Rusniak]

Hi Ujwol,

 

Absolutely can. Here is a screenshot of the NON working Scheme

 

 

Here is the WORKING scheme from my lab:

[Ujwol]

Ah in working case your entity ID doesn't have those special characters (://).

We will need to try with sams entity ID.

If I get time, I will give it a try and let you know.

[Adam Rusniak]

Thank you Ujwol.

[Adam Rusniak]

Kim,

 

Reaching out to see if you have run into this issue? Have to admit I am using the forms auth scheme redirect based on one of your posts I saw and thought was a great idea.

 

Thank you,

 

Adam

[Ujwol]

Sung Hoon Kim this is for you

[SungHoon_Kim]

Hi, I did not have problem but there had been some encoding and decoding that went in and pulled out in the product before.

The way to troubleshoot this is to capture fiddler trace and compare how it should be sent versus how it is send8ng the entityID.

What you can do is to redirect to a custom page instead of redirecting directly to the IDP.

Then at the custom page, you can process the querystring(encode, decode, remove unnecessary parameters ...) then redirect to IDP.

[Adam Rusniak]

Hi Sung Hoon Kim,

 

Thank you for the reply. Yes this is exactly how I have handled it in the mean time. I just created a saml.html page and set this as the target in the auth scheme. On the saml.html page I do a meta refresh instant redirect to the SP Initiated link and it works as expected.

 

I will have to look into the fiddler trace.

 

Adam