[ENHANCE] Ability to generate your own Request ID

[keyCat]

Hello. I am not sure if this request is more related to passport-saml or node-saml package, but probably to both.
I've encountered a use-case where I'd like to be able to generate my own unique request ID.

Is your feature request related to a problem? Please describe.
I would like to be able to store associated data using a Request ID, so later I can retrieve this data from my own store during the callback stage using the ID from InResponseTo field.

Describe the solution you'd like
The easiest approach to a solution (as I see it) is to allow to define your own generateUniqueID() (or even generateUniqueIDAsync()) functions via provider options.

I am using MultiSamlStrategy, so my provider config is generated per request with getSamlOptions(), thus making the use of potential generateUniqueID() possible, but I see how this option would not be very useful during a pre-configured single Strategy use.

I will gladly accept any advice on how to solve this issue any other way, if such a way exists.

Thanks!

UPD: Upon further inspection, I've found out that this was already implemented in node-saml/node-saml@9081e89 but that version of it isn't used by passport-saml yet.

[cjbarth]

Do you mean something like this? node-saml/node-saml#30

[keyCat]

@cjbarth Yes! I didn't notice initially that this was already in the works. Thanks!

[cjbarth]

Feel free to put up a PR with documentation on how to use it.

[srd90]

@keyCat wrote:

I would like to be able to store associated data using a Request ID, so later I can retrieve this data from my own store during the callback stage using the ID from InResponseTo field.

SAML standard has RelayState for that kind of use cases. See more e.g. from: #541 (comment)

Furthermore it seems that passport-saml's RelayState support has had updates recently (see discussion from issue #157 ).

If you (@keyCat) choose to solve your issue with custom request IDs and if you introduce PR suggested by @cjbarth consider also documenting when you should use request ID approach instead of what SAML standard provides otherwise there is a risk that request ID approach (hack) is used by those who do not understand implications of e.g. non-random request IDs etc.