This project is read-only.

Regarding Audience listed in the Authentication Request

Aug 29, 2016 at 6:26 PM
Forgive me as I'm a bit new to SAML authentication but it looks like the Service Provider's ID field is used for both the issuer and the Audience listed under the Audience restriction section of the authentication request.

Is it not possible to list more than one audience in the request? Browsing the source it looks like it only uses the Service Provider ID when generating the request and ignores anything listed in the config's allowedAudienceUris. Is there a reason for this? Is this something that could be configured differently or is it really hard coded to always be the service provider ID?

Thank you for any answers!
Aug 31, 2016 at 4:37 PM
Not in the AuthnRequest, that is hard coded to be the same as the SP ID on purpose. The specification is a LITTLE vague on this, so I'm not sure if this should be changed to open up and allow multiple via allowedAudiences or not... a conservative approach has been taken which only allows the SP to send its ID as an audienceRestriction here.

Whats your use case?
Aug 31, 2016 at 6:53 PM
Actually it sounds like this turned out to be incorrect. However, to explain, my application needs to interact with PING as an IdP and PING was giving errors regarding the authentication request. The group who own the IdP setup thought the audience was incorrect in the request but that appears to not really be an issue.

Instead, it looks like the Single Sign On service's location is something like "[some guid]". When the request is made, it looks like SAML2 will append a "?" before the SAMLRequest is added to the URL so it becomes: "[some guid]?SAMLRequest=[encoded xml string]".

I think it's an issue with how the url is built in the "TransferClient" method of Saml20SignonHandler.cs. The line is the following:
var redirectLocation = request.Destination + "?" + redirectBuilder.ToQuery();

Though, we have both a redirect and a post sign on service available and I'm not sure which SAML2 is actually using right now. It may be an issue in either of those BindingTypes.

I think there just needs to be a check along the lines of:

if (request.destination.contains("?"))
{//url paramters already included in the sing on string
var redirectLocation = request.Destination + "&" + redirectBuilder.ToQuery();
var redirectLocation = request.Destination + "?" + redirectBuilder.ToQuery();

I might be forgetting something here.

Also, thank you for responding!
Aug 31, 2016 at 7:26 PM
Ah, yes, that's probably a good point. Sounds like it's using the redirect binding based on the area of code that you'd be in for it to build the URL that way. The POST builder should be fine because it wouldn't attempt to modify the URL, it would just POST the request over. If you wouldn't mind creating an issue for this, I'll see if I can make a fix for this tonight for you.
Aug 31, 2016 at 7:33 PM
Opened an issue here:

Thank you again for looking into this and responding so swiftly.
Aug 31, 2016 at 7:50 PM
u caught me on a good day. :-)

I'm actually going to migrate this whole project over to GitHub and automate the release deployments for NuGet so that I'm more likely to make small changes like this for people. The big ones that can affect people, as I've said here before, I am leery of making because I no longer have a way to test this library. No one has stepped up to take the ball a little further, but we might get more traction there on GitHub.

In fact, you're a perfect excuse to do it today. So thanks for lighting a fire under me.
Aug 31, 2016 at 8:02 PM
Hey, I'm glad to help you help me!

Look forward to your update, and best of luck on the hop over to GitHub.
Sep 1, 2016 at 12:30 AM
Ok, just pushed it, if you want to continue or have other issues, hit up the new GitHub location:
Sep 1, 2016 at 1:33 PM
Thanks! I replied on the issue listing as well but everything looks good.

Again, thanks so much for the quick responses and corrections.