On 4/11/19 5:07 AM, Manuel Waltschek wrote: Keycloak supports ECP. But from you description it's not clear if you understand the ECP use case. ECP is meant for non-browser (e.g. use without a user agent) authentication. Typically this means command-line tools. The ECP SAML profile requires 3 cooperating parties to be ECP aware: 1) A relying party (typically a web resource, often referred to as Service Provider, i.e. SP). In your case this is where the REST endpoint exists. Usually this means an HTTP server such as Apache with a SAML module loaded, or it could be the JBoss Undertow server part of Wildfly (although I have no personal knowledge of the SAML support in Undertow, others here are probably much more familiar with this). 2) An ECP client, e.g. the command line tool or other non-browser implementation. 3) A SAML assertion provider (e.g. IdP), this would be Keycloak in this instance. The ECP flow works like this: The ECP client requests a resource on the SP (REST endpoint), it indicates it wants ECP. The SP returns a SOAP document to the ECP client containing an authentication request. The ECP client forwards the authentication request to the IdP (e.g. Keycloak) along with authentication credentials (recall ECP is meant for non-interactive use). The IdP returns the authentication result (i.e. SAML Assertion) to the ECP client. The ECP client then forwards it to the SP. The SP will then return the original requested resource. Note, this is a simplified explanation. Hopefully you can see from this description that the fact the protected resource is a REST endpoint or the fact it's invoked by a third party has little bearing on the choice of using the ECP SAML profile. Rather I think what you're looking for is how to perform delegation, a different topic. -- John Dennis