Can I access query parameters in Velocity templates?

[Wurbs, Holger]

Hello,

I might misunderstand the purpose but isn't that something you specifically added to the IdP?

Looking at this: https://shibboleth.net/pipermail/commits/2020-April/045492.html

The idea is to set the following property to true:

idp.logout.preserveQuery = true

then query parameters get saved in ScratchContext and can be accessed in .vm like so:

#set ($scratchContext = $profileRequestContext.getSubcontext("org.opensaml.messaging.context.ScratchContext"))
#set ($queryValue = $scratchContext.getMap().getOrDefault("[QueryParam]", [""])

I have done this for logout purposes before. Not 100% certain if it is applicable in this scenario though.

Regards,
Holger Wurbs

———————————————————
Hochschule Düsseldorf
University of Applied Sciences

———————————————————
 

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Scott Cantor via users
Sent: Tuesday, April 21, 2026 7:47 PM
To: Shib Users <users at shibboleth.net>
Cc: Scott Cantor <scott at restingparrotsoftware.com>
Subject: Re: Can I access query parameters in Velocity templates?



> On Apr 21, 2026, at 1:18 PM, Wessel, Keith via users <users at shibboleth.net> wrote:
> 
> I think the answer is no, but I wanted to make sure.

Most views receive request and response variables populated with the servlet request and response, so certainly, yes, but by the time any views run the original parameters the IdP gets are long gone due to how webflow works.

> I've already got our logout.vm redirecting to Entra's logout endpoint, but I've had a request to try and pass an extra parameter sent by the originating SP to Entra's logout endpoint.

Embedding proprietary behavior that you can't really depend on is just asking for trouble IMHO, but by the same token, logout is just...so stupid on every level that I can't get terrible exercised about it.

The real question to me is why anybody needs a "parameter". At this point, non-admin logout should simply be blindly/trivially acting on the browser's cookis and be done with it. The entire concept of a protocol for it is just so obviously flawed and silly that I can't do much but apologize for ever having had a hand in one. It is amazing to me that OpenID repeated the same dumb choice to have a protocol around it that requires all sorts of hassles.

I'm all but planning to essentially not even pay attention to the logout messages in the SP4 work and just treat them as "sure, whatever, logout, done". There's no significant threat model here and I get that.

> That means passing it through /idp/profile/Logout, through the template, and appending it to the Entra logout URL. For all kinds of reasons, I'm thinking it's a bad idea, but I'm wondering if it's even possible.

Yes, but possibly not without extra work, and possibly not via that particular endpoint. I know how I'd do it for a SAML logout because we have processing hooks but that endpoint isn't like those.

It's possible the original/first view that pops up there might have access to them, I don't know. They'd have to be stashed from there to get at them by the time it's finishing anything.

I have debated just adding a front-end step to every flow that captures the original parameter set to stash them and just have an option that does it all the time.

-- Scott

-- 
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net