I'm not sure how useful this is, nor do I think it's particularly safe. There's nothing to stop someone sending a request and masking a different IP address. It would have to use mutual SSL to be secure. Or at least use SSL and have a callback (to confirm that request comes from the actual host), but then it's not using the OIDC standard protocol anymore.

Let's discuss it in more detail when you're back from PTO.

On 11 August 2016 at 17:30, Marek Posolda <mposolda@redhat.com> wrote:

According to the specification
http://openid.net/specs/openid-connect-registration-1_0.html#ClientRegistration
there is this:

"To support open Dynamic Registration, the Client Registration Endpoint
SHOULD accept registration requests without OAuth 2.0 Access Tokens.
These requests MAY be rate-limited or otherwise limited to prevent a
denial-of-service attack on the Client Registration Endpoint."

So it looks we need to have a way to allow dynamic client registrations
even without Initial Access Token. Without supporting it, we are not
able to move forward with OIDC conformance testsuite with "Dynamic"
profile as it seems there is not a way to retrieve initialAccessToken
from Keycloak and "inject" it to conformance testsuite.

So I've added the possibility to define trusted hosts under "Initial
Access Tokens" tab. Client registration requests from those hosts are
permitted even without initial-access-token . It's possible to limit the
count of registrations for each host similarly like is for "Initial
Access Tokens".

This approach allows to move forward with OIDC Conformance testsuite
with "Dynamic" profile.

If you agree and we move forward with this approach, then we should
consider to rename "Initial Access Tokens" tab to "Client Registration"
or "Dynamic Client Registration" ? As Initial Access Tokens are anyway
related just to dynamic client registrations.

WDYT?

Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev