[OpenSAML] Extra Query parameter (HTTP Redirect Binding)

[rangeli nepal]

Good Afternoon Everybody,

I send AuthnReuqust to IDP using HTTP Redirect binding. I am
successful in sending it if my endpoint location looks like following:

https://abc.net/loginservice/login/

Now I like to send an extra query parameter using this binding. I
thought if I just change the endpoint location i.e

https://abc.net/loginservice/login/?status=1

Thing should work. It did not. It puts the reglar parameters i.e
(SAMLRequest,SigAlg,Signature) but status does not appear in query
parameter.

am I missing something.?
Thank you.
rn

[Cantor, Scott E.]

On 3/21/11 1:17 PM, "rangeli nepal" <rangel...@gmail.com> wrote:
>Now I like to send an extra query parameter using this binding. I
>thought if I just change the endpoint location i.e

That is not a legal use of the Redirect Binding.

-- Scott

[rangeli nepal]

I thought specification is mute about it. It just talks about
essential query parameters and some extent ordering. It does not talk
about extra query parameter.
rn

[Deena Gurajala]

I did come across this kind of usage, but on IDP side. The redirect biding does not specify how to identify the key name used to verify the digital signature. Also the signature must not be in the SAML request (POST is allowed to have signature in side the XML).

What I did was I extended the class used to send Redirect Response and overwrite the method and add your parameter. In my case I overwrite buildRedirectURL() method. My extended class looks like below. I think it is same for request or response. I think you can use this code.

public class RedirectEncoder extends HTTPRedirectDeflateEncoder {

    private static final Logger logger=Logger.getLogger(RedirectEncoder.class);
   
    private String keyname;
   
    public RedirectEncoder(String keyName){
        super();
        this.keyname=keyName;   
    }
   
    public RedirectEncoder(){
        super();
    }
    /**
     * Builds the URL to redirect the client to.
     *
     * @param messagesContext current message context
     * @param endpointURL endpoint URL to send encoded message to
     * @param message Deflated and Base64 encoded message
     *
     * @return URL to redirect client to
     *
     * @throws MessageEncodingException thrown if the SAML message is neither a RequestAbstractType or Response
     */
    @SuppressWarnings("unchecked")
    protected String buildRedirectURL(SAMLMessageContext messagesContext, String endpointURL, String message)
            throws MessageEncodingException {
        logger.debug("Building URL to redirect client to");
        URLBuilder urlBuilder = new URLBuilder(endpointURL);

        List<Pair<String, String>> queryParams = urlBuilder.getQueryParams();
        queryParams.clear();

        if (messagesContext.getOutboundSAMLMessage() instanceof RequestAbstractType) {
            queryParams.add(new Pair<String, String>("SAMLRequest", message));
        } else if (messagesContext.getOutboundSAMLMessage() instanceof StatusResponseType) {
            queryParams.add(new Pair<String, String>("SAMLResponse", message));
        } else {
            throw new MessageEncodingException(
                    "SAML message is neither a SAML RequestAbstractType or StatusResponseType");
        }

        String relayState = messagesContext.getRelayState();
        if (checkRelayState(relayState)) {
            queryParams.add(new Pair<String, String>("RelayState", relayState));
        }

        Credential signingCredential = messagesContext.getOuboundSAMLMessageSigningCredential();
        if (signingCredential != null) {
            String sigAlgURI = getSignatureAlgorithmURI(signingCredential, null);
            Pair<String, String> sigAlg = new Pair<String, String>("SigAlg", sigAlgURI);
            queryParams.add(sigAlg);
            String sigMaterial = urlBuilder.buildQueryString();

            queryParams.add(new Pair<String, String>("Signature", generateSignature(signingCredential, sigAlgURI,
                    sigMaterial)));
        }
        queryParams.add(new Pair<String, String>("KeyName", keyname));
       
        String queryString=urlBuilder.buildURL();
        if(logger.isDebugEnabled()){
            logger.debug("Query String ==>"+queryString);
        }
       
        return queryString;

[Cantor, Scott E.]

On 3/21/11 1:33 PM, "rangeli nepal" <rangel...@gmail.com> wrote:
>I thought specification is mute about it. It just talks about
>essential query parameters and some extent ordering. It does not talk
>about extra query parameter.

It does not allow them, because the binding itself makes use of those
parameters. If you want to carry other information, you do it with SAML
extensions.

-- Scott

[rangeli nepal]

I am reading saml-binding-2.0, On page 17(line 566,567) says:

"A URL encoding MUST place the message entirely within the URL query
string, and MUST reserve the
rest of the URL for the endpoint of the message recipient."

I thought this means the protocol allows extra query string. Is this
not the intent of above statements?

I do agree we should not use the name of query parameter that
conflicts with the parameter name that protocol uses
Thank you.
rn

[Cantor, Scott E.]

On 3/21/11 2:10 PM, "rangeli nepal" <rangel...@gmail.com> wrote:
>I am reading saml-binding-2.0, On page 17(line 566,567) says:
>
>"A URL encoding MUST place the message entirely within the URL query
>string, and MUST reserve the
>rest of the URL for the endpoint of the message recipient."
>
>I thought this means the protocol allows extra query string. Is this
>not the intent of above statements?

That text is talking about defining alternate URL encodings within the
overall binding, which was an extension point. I had forgotten that it
existed, but the text in question is precluding the use of Path Info as
part of the URL encoding.

For the purposes of what you're trying to do, you would have to define an
alternate URL encoding, and attach that explicit parameter to identify
that it's an alternate one to the default. By using a superset of the
original encoding, you could achieve at least a semblance of
compatibility, but with no guarantee that a strict peer wouldn't reject it.

-- Scott

[rangeli nepal]

Thank you Deena,

Well it very good hint and will definitely work if you manage both
client and server.
rn