Hi,
Thanks Hynek, I have filed two feature request jiras:
*
https://issues.jboss.org/browse/KEYCLOAK-12000: Allow overriding time
lifespans on a SAML client
*
https://issues.jboss.org/browse/KEYCLOAK-12001: Audience support for
SAML clients
Can I assign them to me? The first one is extremely easy (although I
have to wait to have the new console I suppose) and the second is more
complicated because it's a new type of protocol mapper (one that
receives the SAML builder or similar) but I can work on them when I have
time. I suppose there is no hurry for those two JIRAs.
About the little PoC I'll make an entry with this in my blog when
keycloak 8 is out (for the moment you need to compile it to have the
assertion with the signature in the saml subject).
Regards!
On 11/11/19 9:46 AM, Hynek Mlnarik wrote:
Hi Ricardo,
On Sat, Nov 9, 2019 at 5:43 PM Ricardo Martin Camarero
<rmartinc(a)redhat.com <mailto:rmartinc@redhat.com>> wrote:
Hi,
I have been playing with the assertion replaying that was
introduced a
few weeks ago [1] to do a real example. My PoC consists in a keycloak
SAML adapter that calls a CXF endpoint protected by a
"WssSamlV20Token11" wss4j policy. The wss4j uses opensaml
implementation
so, this way, we test the feature using a different implementation
and
in a real scenario. The summary is:
Keycloak APP -> SAML login -> recover the signed assertion from the
subject -> call CXF endpoint with the signed assertion -> WS
executed OK
And it works, but I have seen two snags:
That's neat, thanks for doing this!
1. The assertion is created with very short periods of validity
(SubjectConfirmationData and Conditions, NotOnOrAfter attribute). The
values are taken from the realm timeouts [1] and the problem is that
those values cannot be overridden for the client like in OIDC. So the
short timeouts for OIDC are not suited for SAML if replay is used. In
normal web SAML this is not important because the
assertion/response is
only checked once at login time.
We'd need an option to override assertion lifespan similar to OIDC
client's "Access Token Lifespan" in Advanced, just as you suggest
below. Feel free to add a RFE.
2. The other problem is the audience, the audience is set only to the
clientId (same lines in [1], it's the requestIssuer, that later is
set
to the audience in the SAML assertion). When replaying more values
are
needed, one for each final endpoint in which the assertion is
going to
be used. I think SAML audience should also be customizable with
several
values like in OIDC.
+1 This would deserve a separate RFE. Doing it via a mapper similar to
OIDC case seems worth investigating. I believe this benefit of being
accompanied a SamlAuthenticationPreprocessor implementation to put it
into a proper place within the SAML assertion - mapper would set the
audience into client session attributes and the preprocessor update
the assertion accordingly.
Any SAML implementation verifies those restrictions and gives an
error
if any condition is wrong (CXF/opensaml checks the audience with the
endpoint URL and all the time restrictions). I think that those two
points should be improved in order to fully have assertion replay
ready
to be used in the SAML clients. What do you think? Two RFEs?
Regards!
[1]
https://issues.jboss.org/browse/KEYCLOAK-10757
[2]
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/o...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Ricardo Martín Camarero
Software Engineer
Red Hat <
https://www.redhat.com>
<
https://www.redhat.com>