Re: [saml-dev] OneTimeUse Clarification

To the extent that it has any meaning at all, it would be relevant to cases where a normally reusable security token in a web service call or similar context was intended to be limited toÂoneÂuse. That's the sort of thing the condition would work for.

Ok, could this for example be in the case of using SAML with web services? And thenÂinstead of allowing the sender to reuse a token for each request would force the sender to get a newly issued one for each request?

ÂNobody's going to deploy server side state just to do replay checks in SAML, so practically speaking, the real limiting factor is the freshness check.

Interesting. Do you mean that implementations generally do not store the assertion id of receivedÂassertion and check incomingÂassertion for replay using this? Instead only relying on the NotAfter attributes?

Stefan

On Fri, Nov 13, 2020 at 3:33 PM Cantor, Scott <cantor.2@osu.edu> wrote:

On 11/13/20, 2:12 AM, "Stefan Rasmusson" <rasmusson.stefan@gmail.com> wrote:

>Â Â HiI have seen several discussions on the use and meaning of the OneTimeUse element.

I've really never seen it come up, which is for the best.

>Â Â If this is the case, why does both the SAML security considerations and then OWASP projects documentation on SAML
> recommend using it?

I wasn't aware the former did, and I certainly wouldn't go by anything OWASP says about SAML. That condition plays no role in any defined SAML profiles.

>Â Â If it's not, what are the use cases of allowing an assertion to be replayed?

To the extent that it has any meaning at all, it would be relevant to cases where a normally reusable security token in a web service call or similar context was intended to be limited to one use. That's the sort of thing the condition would work for.

In effect it's a signal that if a profile allowed for reuse, the token should be guarded for replay. SSO does not allow reuse, period, so it has no need for such a condition, it's implied.

>Â Â Lastly, any ideas on implementations generally handle this? As I understand web browser profiles should discard >duplicates even without this, but do most implementations?

From my testing at times, most random implementations do tend to prevent replay at least in some primitive way on a single server. Nobody's going to deploy server side state just to do replay checks in SAML, so practically speaking, the real limiting factor is the freshness check.

-- Scott

saml-dev message