[keycloak-dev] Wildcard for Valid Redirect URI Hostname

Wed Sep 21 02:13:50 EDT 2016

There's client registration services that does this. It allows creating,
updating and deleting clients. See
https://keycloak.gitbooks.io/securing-client-applications-guide/content/topics/client-registration.html

Then there's also the admin endpoints as Scott pointed out.

On 20 September 2016 at 16:49, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Great discussion with a lot of interesting points!
>
> I think being more flexible with respect to redirect URI's would be very
> helpful.
>
> 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.
>
> Cheers,
> Thomas
>
> 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/20160921/5615f4fc/attachment.html 