Distiguishing between apps by URL parameter?

[Kevin LaBarre]

Thanks Scott.

This is not a security issue in this situation.  Even though I want to use the query, we're matching on numbers only so case is not an issue either.  It sounds like the usual way to do this would be to modify the path itself to distinguish between applications, not the query.  If necessary, I can do this but the design of the application as-is means this would require some work so it was not my first choice.  I could not tell from your response... is it even possible to define the applicationId based on the query?  I don't believe this is supported according to what I've read... in which case all this isn't even possible with Shibboleth.



Best regards,

Kevin F. La Barre
Senior IT Engineer
AssetWorks, Inc.
512-347-7400 x1860

-----users-bounces at shibboleth.net wrote: -----

To: "users at shibboleth.net" <users at shibboleth.net>
From: "Cantor, Scott" <cantor.2 at osu.edu>
Sent by: users-bounces at shibboleth.net
Date: 12/19/2011 11:46AM
Subject: Re: Distiguishing between apps by URL parameter?

On 12/19/11 12:37 PM, "Kevin LaBarre" <Kevin.LaBarre at Assetworks.com> wrote:
>
>Due to my configuration I would like to proceed with the Query feature
>within the RequestMapper in the shibboleth2.xml file, but I seem to be
>able to get one app or the other working just fine, but not both.  It
>seems only "default" works and it's got to be something with the way I'm
>defining things.

Yes, you're defining the applicationId based on the path, and not the
query.

>Right now my RequestMapper definition looks something like this:

In that scenario the application demarcation is non-existent, so
everything is default.

>I need to be able to distinguish between two applications by the query.
>I've searched extensively but have not been able to find any examples on
>how this should be done.


Because it's usually a very bad idea; query string evaluation is case
sensitive, and almost no language honors that. So subverting your intent
tends to be fairly simple. That may be merely functionally problematic,
but if it's security-relevant, you'd have a problem.

>  My first attempt (which failed) looks something like this:

You can't define two PathRegex elements that are identical. One overwrites
the other. And you can't define the application override in terms of the
Path if you want it to be based on the query. You need to eliminate the
duplication and then move the applicationId into one or both of the
queries. Most likely it will be clearer to define an override for each
one, rather than only one of them. That way it's more explicitly parallel.
It will work as default + override, but some find that confusing.

>I then proceed with the ApplicationDefaults section where again I'm
>confused about how things work.  From the documentation it looks like I
>should declare the defaults first, then setup an ApplicationOverride
>section.  Is ApplicationOverride defined within the ApplicationDefaults
>section or outside of those tags altogether?

Inside, emphasizing the inheritance of most of the settings. The
documentation shows this explicitly by describing all settings in terms of
what's permitted where.

>Unfortunately I found examples both ways and I know one has to be wrong
>so I figured I'd ask anyway.

Any examples showing them as siblings wouldn't even load.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20111219/b92c275e/attachment.html