Issues with KeyCloak SAML2 SPs?

[o haya]

I agree with both of Michal's comments/suggestions.

Also, if possible, for a test, maybe try to get the entire path down to a
single-threaded path, so that nothing is doing round-bin  or clustering. I
think that will be the only way to figure this kind of problem where it is
happening intermittently.  You need to get to a single-threaded path where
it fails consistently, then figure out which component is causing the
failure.

On Wed, Nov 26, 2025 at 9:42 PM Michael Grady <mgrady at unicon.net> wrote:

> According to the AI summary in front of my search results, KeyCloak
> supports a clock skew setting, BUT it is set to zero (no allowed skew) by
> default. If that is true, and they did not think to adjust that setting,
> that could indeed be the problem. You could get them to look, or you could
> simply have a relying party override for that SP to not send NotBefore and
> see if that solves the problem.
>
> Mike Grady, Unicon
>
> On Nov 26, 2025, at 8:36 PM, Michael Grady <mgrady at unicon.net> wrote:
>
> One possibility I’d consider is their server clock management, and/or
> whether they have things configured to support some clock skew.  It has
> been a few years, but there was a vendor we integrated with whose SP config
> did not support any clock skew. And even if both sides are synced to the
> same standard time source, clocks can be off by milliseconds, and that was
> enough — intermittently, but still often — to cause the SAML response to be
> rejected because of the NotBefore attribute in the response. Which is why I
> worked with Scott (we are talking back in 2012/13) to get the relying party
> override to have an option to NOT send the NotBefore attribute in the
> response.
>
> Mike Grady, Unicon
>
> On Nov 26, 2025, at 7:07 PM, IAM David Bantz via users <
> users at shibboleth.net> wrote:
>
> 
> Thank you for the response.
> Our IdP side uses sticky sessions and I can verify that the successful and
> unsuccessful sign-ins for the same user were issues from the same IdP node.
> But when we next meet, I will raise that issue for the vendor to examine
> on the SP side.
>
> David Bantz
>
> On Wed, Nov 26, 2025 at 3:13 PM o haya <ohaya1001 at gmail.com> wrote:
>
>> Hi,
>> Is there any clustering/round robin going on in the path somewhere?  That
>> might explain why you are seeing problems intermittently?
>>
>> On Wed, Nov 26, 2025 at 4:22 PM IAM David Bantz via users <
>> users at shibboleth.net> wrote:
>>
>>> We set up SSO with a vendor that relies on KeyCloak as the SAML2 SP
>>> interface. Are other users here aware of sporadic but plentiful failures
>>> with similar set-up? If so, we're desperate for potential remedies to offer
>>> to the vendor.
>>>
>>> The iterative process to set up SAML2 SSO was frustrating as many
>>> aspects of SAML practices were apparently unknown to the vendor. But we
>>> have a seemingly complete integration in routine production. However many
>>> users - both naive users and experienced skilled users reproducing
>>> students' experiences - report failures at the service despite normal
>>> successful SSO and SAML response from the IdP to SP. We have repeatedly
>>> copied the exact SAML response (prior to encryption) to the vendor asking
>>> them to review their own logs to determine why students were occasionally
>>> being stopped. In some cases, a second or third sign-in attempt - seemingly
>>> identical to failed attempts - succeeds. We've provided examples of the
>>> exact same SAML response (save timestamps and transient nameID) that
>>> succeeds one time, fails another. Responses to have been, essentially,
>>> expressions of puzzlement; we have not seen any detailed logs from either
>>> KeyCloak or the service being protected. We've been stuck in this loop for
>>> 6 weeks; this is a mission critical service owned locally by our
>>> Registrars, who are understandably frustrated and despondent and have
>>> inboxes flooded with complaints from students unable to get needed service.
>>>
>>> I did not mention the vendor or service to avoid flack, but will if it
>>> helps; many of you would recognize them.
>>>
>>> David St PIerre Bantz
>>> UA IAM
>>>
>>> --
>>> 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
>>>
>> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20251128/1c5711d5/attachment.htm>