Re: [keycloak-dev] saml assertion replay

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