Request id inaccessible

[brotherbain]

I noticed that you're able to hand a request id over to process_response. After scouring the code, it seems to me that that request id is not actually accessible. The id seems to be generated by a temporary authn_request object which is discarded after creating the redirect url. If it isn't saved anywhere, how can it ever be used without decoding the url again before sending? Did I miss something?

[pitbulk]

Hi @brotherbain,

You are right, the toolkit provides the login method at Auth class that generates the AuthNRequest and you are right if you use that, you can't get the ID in an easy way.

Most of the Service Provider deployed will allow IdP- initiaited SSO so don't care about the AuthNRequest ID and don't make a validation when processing the SAMLResponse.

Instead of be using the login method, you can code something like:

        settings = auth.get_settings()

        authn_request = OneLogin_Saml2_Authn_Request(settings, force_authn, is_passive)

        saml_request = authn_request.get_request()
        authn_request_id = authn_request.get_id()
        parameters = {'SAMLRequest': saml_request}

        if return_to is not None:
            parameters['RelayState'] = return_to
        else:
            parameters['RelayState'] = OneLogin_Saml2_Utils.get_self_url_no_query(auth.__request_data)

        security = settings.get_security_data()
        if security.get('authnRequestsSigned', False):
            parameters['SigAlg'] = security['signatureAlgorithm']
            parameters['Signature'] = auth.build_request_signature(saml_request, parameters['RelayState'], security['signatureAlgorithm'])
        return auth.redirect_to(auth.get_sso_url(), parameters)

Same happens on the LogoutResquest method

I wanted to avoid more complexity on the login method, that means not 100% of the cases covered with a hight level method, but you can always use the functionalities that the toolkit provides.

If you have a suggestion of adding a mechanism to collect the ID of the Request that not add extra complexity on the toolkit, please share it.

[brotherbain]

I think simply saving the request id to self.__request_id with an accessor in similar fashion to other variables that may need to be referenced outside the class would work just fine. you wouldn't have to change login's interface, and then you have a way to make use of that great request_id validator that's currently collecting dust in the process_response method. Security is key to all authentication, and that little check goes a long way toward preventing replay attacks on this otherwise-exceptional library. What do you think?

[brotherbain]

oops! after a second look, it really looks like it should be the authentication request that is saved to self.__auth_request with an accessor. then you could:

saml_auth = OneLogin_Saml2_Auth(req, settings)
response = saml_auth.login()
session['saml_request_id'] = saml_auth.get_auth_request().get_id()
return redirect(response)

[pitbulk]

The self.__request_id solution does not solve the problem since you need to store the ID value and the login and logout method executes a redirection when called.

So I need to extend login and logout methods to support the "stay" parameter that determines if the redirection is done or not.

Edit: This happened in other toolkits, not in python.

[brotherbain]

So far as I can tell, they merely create a url for redirection, but that url can be withheld until the system is ready to return it. the rest can be up to the user. it's far better, I'd say, than having a parameter in your process_request method that is unusable. I agree that perhaps it isn't ideal either. Just throwing out ideas 😄

[pitbulk]

At the python toolkit and ruby-saml, the redirection is executed by the python/ruby framework instead of the toolkit, the SSO/SLO url + samlrequest is returned by the login/logout method.

At the php toolkit and at the java-saml toolkit. the redirection is executed.

I think I will implement an "stay" option at java-saml and php-saml and let developers retrieve the request ID as you asked for. But I dislike the idea of saving the request object at the auth object.

The alternative as you also suggested is the get_request_id(), saving previously the id at the auth object when login/logout executed, but I dislike the fact that this field only belong the requests and only available after execute the login/logout method.

[brotherbain]

I agree it does feel a bit clunky. hmmm... I'll be thinking about this a bit more, then. a better answer may yet reveal itself. Thanks for hearing me out!