[keycloak-dev] Wildcard for Valid Redirect URI Hostname

Thomas Darimont thomas.darimont at googlemail.com
Tue Sep 20 10:49:00 EDT 2016

Great discussion with a lot of interesting points!

I think being more flexible with respect to redirect URI's would be very

I wonder whether one could provide a REST endpoint a developer could use to
register an additional redirect URI
for an existing client - given that the developer provides the clientId,
clientSecret -> service account.

With this a developer could "unlock" his machine enable for a particular
client. One way to do that would be to register a custom REST Resource in
Keycloak which only allows requests from the service-accounts of a
particular client. The resource could then simply lookup the appropriate
client configuration and update the allowed redirect paths.

Adding paths should trigger an AdminEvent to provide an audit trail.


2016-09-20 16:15 GMT+02:00 Josh Cain <josh.cain at redhat.com>:

> So I certainly get that we want to be as close to the spec as possible -
> wholeheartedly agree.  However, I'd also like to reiterate that the main
> purpose of this is for lower/developer environments in which there are a
> large number of developers who are frequently spinning up sanboxes with
> apps that need SSO capabilities.  Unless I want to open up the GUI in these
> environments to the world, I'm left without a good CM option for Keycloak.
> Any suggestions on the management of this?  Right now I'm looking at a high
> amount of manual overhead, or scripting it out with some one-off config
> scripts that I'll have to wind up maintaining.  Neither option sounds
> appealing.
> Hope you didn't get the wrong impression from the PR - I noted a
> javascript library that was shared across several pages within a number of
> subdomains.  All pages share a similar look and feel, but due to the nature
> of the content and topic can live at different subdomains or even have
> slightly different page content implementations.  Are we really going to
> make the assertion that a 'client' cannot span subdomains?  That seems to
> be the implication here.  And if so, is that necessarily more 'secure', or
> does that just mean that implementers could simply favor a single domain
> name with varying paths instead of categorically organized subdomains?
> Seems like an implementation detail that can easily be circumvented and
> does not inherently make an enclave more or less secure.
> I completely agree with your argument that we should be striving for the
> finest level of granularity with respect to client definition.  I
> understand the intentional segregation of logical clients by the
> specification so as to keep one compromised client from affecting the
> entire SSO ecosystem.  However, I do think that there is a solid case for a
> single 'client' that does stuff like spans subdomains, and that such a
> client could be used in a secure manner.
> At the end of the day, it feels like we're trying to force a definition on
> what is a client.  The discussion seems to acknowledge that 'real world'
> application of this spec find wildcards useful (as your suggestion for
> supporting them in the path), however the manner in which they're used
> appropriately is up for debate.  If we're living outside the spec anyway,
> do we really have a firm leg to stand on for the assertion that clients can
> have different paths but not subdomains?  I don't see a solid reason for
> this one.
> Some other thoughts I had on this that might be useful:
>    - Some of the rub here is that maintaining a list of valid redirects
>    for something like string matching is a CM nightmare (particularly in
>    dev-ish environments).  Something like an SPI to drop an implementation in
>    here where I can apply a little more powerful logic would also do the job.
>    Could this be used nefariously or poorly to circumvent the specification?
>    yeah, sure - but so can Authenticators, and they're seen as a useful tool
>    whereby developers can extend necessary functionality.
>    - Would you also consider something like a 'development mode' flag
>    that allowed for different options such as wildcards in different URL
>    parts?  Would have to add a little more validation to define what is and is
>    not allowed, but would be useful for this case.
> Thanks for good the discussion.  As always, learning much and enjoying it!
> Josh Cain | Software Applications Engineer
> *Identity and Access Management*
> *Red Hat*
> +1 256-452-0150
> On Tue, Sep 20, 2016 at 1:20 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>> I appreciate this feature might be useful, so there's no need to discuss
>> that aspect. The only issue I have with this PR is with regards to security
>> and especially as it enables doing the "wrong" thing.
>> With regards to redirect URIs with confidential clients they are still
>> important, but not quite as important as they are for public client. This
>> means redirect URIs can typically be more flexible with confidential
>> clients without a significant risk.
>> For public clients it's very important to lock these down as much as
>> possible as they are the ONLY way to prevent malicious clients to gain
>> access to the SSO session. This means we should actually tighten the
>> requirements for redirect URIs not further relax them. For public clients
>> the redirect URIs:
>> * Should be as specific as possible. We should only allow wildcard in the
>> path. I believe we should introduce this for both public and confidential
>> clients.
>> * Require HTTPs unless it's http://localhost. This is not so easy in
>> development, so maybe we should have an option to run the server in
>> "unsafe" mode for developers.
>> Here's a quote from the OIDC spec around this:
>> *"REQUIRED. Redirection URI to which the response will be sent. This URI
>> MUST exactly match one of the Redirection URI values for the Client
>> pre-registered at the OpenID Provider, with the matching performed as
>> described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The
>> Redirection URI SHOULD use the https scheme; however, it MAY use the http
>> scheme, provided that the Client Type is confidential, as defined in
>> Section 2.1 of OAuth 2.0, and provided the OP allows the use of http
>> Redirection URIs in this case. The Redirection URI MAY use an alternate
>> scheme, such as one that is intended to identify a callback into a native
>> application."*
>> Looking at your comments on the PR it worries me slightly that you have a
>> shared client for a "library". A library is not a client. A client is an
>> instance of an application. Sharing the client will have impact on audit,
>> what clients a user believes they are authenticated to. With regards to
>> wildcard to allow any subdomains that is scary as your allowing any piece
>> of code running on any subdomain within your domain to authenticate via
>> that particular client. That could be an infected forum, something any user
>> has executing, etc.. As long as the redirect URI permits it an application
>> can obtain a token for a client for a user that is authenticated without
>> the user knowing about it. Unless you enable consent that is, but if the
>> user used the "real" client they would have given consent and the malicious
>> client on a different subdomain can take advantage of it.
>> In summary my opinion is that we can't accept this PR and that we further:
>> * Allow wildcard only in path. This is actually still looser than the
>> OIDC spec mandates as it requires a simple string comparison.
>> * Require HTTPS (or custom scheme) for public clients. We may need a
>> development mode that disables this.
>> On 19 September 2016 at 16:50, Josh Cain <josh.cain at redhat.com> wrote:
>>> Per KEYCLOAK-3585: <https://issues.jboss.org/browse/KEYCLOAK-3585>
>>> Currently, valid redirect URI hostnames allow for wildcards at the end
>>> like so:
>>> http://www.redhat.com/*
>>> I'm managing several environments where clients need 'n' number of
>>> available redirect URI's with different hostnames, I.E.
>>> http://developer1.env.redhat.com
>>> http://developer2.env.redhat.com
>>> http://developer3.env.redhat.com
>>> Would really help to have the ability to wildcard hostnames too, I.E.:
>>> http://*.env.redhat.com
>>> I've submitted #3241 <https://github.com/keycloak/keycloak/pull/3241>
>>> to address this issue, but there seem to be some concerns about allowing
>>> wildcards in other parts of the URL.  See the PR for a more fleshed out
>>> discussion, but wanted to start a thread here on the mailing list.
>>> Particularly with respect to:
>>>    - Does anyone have need of this feature or would find it useful?
>>>    - Should this kind of wildcard be allowed as a configuration option
>>>    by Keycloak?
>>> Josh Cain | Software Applications Engineer
>>> *Identity and Access Management*
>>> *Red Hat*
>>> +1 256-452-0150
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160920/d2ad1ba4/attachment.html 

More information about the keycloak-dev mailing list