7 a.m.
I propose we remove the realm json returned at "/auth/realms/<realm
name>"
and just return an empty page
* It can end-up being visible to end-users - we should rather have a realm
welcome page / SSO landing page here
* It's not used by anything AFAIK
* From time to time people complain about it (
https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more
similar issues reported)
12:18 p.m.
The idea of that URL is to expose public information about the realm,
i.e. public cert/key and public endpoint urls. If this information is
not being used and we have other mechanisms in place, then yeah, remove it.
IMO, the jira you reference is unrelated. Its about shutting down the
admin console/API. As far as that goes, it would be cool to split up
keycloak into separate subsystems:
* backend (required)
* admin api/console
* account service
* authentication/brokering/token endpoints
Even have the admin api/console be exposed from a different bind
address/port.
On 8/15/17 8:00 AM, Stian Thorgersen wrote:
I propose we remove the realm json returned at
"/auth/realms/<realm name>"
and just return an empty page
* It can end-up being visible to end-users - we should rather have a realm
welcome page / SSO landing page here
* It's not used by anything AFAIK
* From time to time people complain about it (
https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more
similar issues reported)
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:55 a.m.
Why split it into multiple subsystems? Are you only talking about the
ability to enable/disable? If so that can easily be added through the
profile feature like we do for authorization services. That's probably 2
min work.
The ability to expose admin endpoints on a different address/port would be
great.
On 15 August 2017 at 19:18, Bill Burke <bburke(a)redhat.com> wrote:
The idea of that URL is to expose public information about the
realm,
i.e. public cert/key and public endpoint urls. If this information is
not being used and we have other mechanisms in place, then yeah, remove it.
IMO, the jira you reference is unrelated. Its about shutting down the
admin console/API. As far as that goes, it would be cool to split up
keycloak into separate subsystems:
* backend (required)
* admin api/console
* account service
* authentication/brokering/token endpoints
Even have the admin api/console be exposed from a different bind
address/port.
On 8/15/17 8:00 AM, Stian Thorgersen wrote:
> I propose we remove the realm json returned at "/auth/realms/<realm
name>"
> and just return an empty page
>
> * It can end-up being visible to end-users - we should rather have a
realm
> welcome page / SSO landing page here
> * It's not used by anything AFAIK
> * From time to time people complain about it (
> https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more
> similar issues reported)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:12 a.m.
KEYCLOAK-5279 isn't asking to split it out. We're dealing with the access
at a network level, making it so that certain URIs aren't accessible. But
the ability to hide the fact that it may need to exist is important.
I think the more relevant ticket is KEYCLOAK-5277, where at least in a
multitenant fashion the fact that a realm may exist is considered sensitive
information. The fact that there's a public API that returns 200/404 if a
realm exists is considered a problem, so having it removed would alleviate
any concerns in that area.
On Tue, Aug 15, 2017 at 1:19 PM Bill Burke <bburke(a)redhat.com> wrote:
The idea of that URL is to expose public information about the
realm,
i.e. public cert/key and public endpoint urls. If this information is
not being used and we have other mechanisms in place, then yeah, remove it.
IMO, the jira you reference is unrelated. Its about shutting down the
admin console/API. As far as that goes, it would be cool to split up
keycloak into separate subsystems:
* backend (required)
* admin api/console
* account service
* authentication/brokering/token endpoints
Even have the admin api/console be exposed from a different bind
address/port.
On 8/15/17 8:00 AM, Stian Thorgersen wrote:
> I propose we remove the realm json returned at "/auth/realms/<realm
name>"
> and just return an empty page
>
> * It can end-up being visible to end-users - we should rather have a
realm
> welcome page / SSO landing page here
> * It's not used by anything AFAIK
> * From time to time people complain about it (
> https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more
> similar issues reported)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:48 p.m.
On 16 August 2017 at 12:12, John D. Ament <john.d.ament(a)gmail.com> wrote:
KEYCLOAK-5279 isn't asking to split it out. We're dealing
with the access
at a network level, making it so that certain URIs aren't accessible. But
the ability to hide the fact that it may need to exist is important.
I think the more relevant ticket is KEYCLOAK-5277, where at least in a
multitenant fashion the fact that a realm may exist is considered sensitive
information. The fact that there's a public API that returns 200/404 if a
realm exists is considered a problem, so having it removed would alleviate
any concerns in that area.
Firstly, I disagree that exposing if a realm name is a valid realm or not
is not a particular big risk. Folks can find valid realm names just by
logging in to your apps.
Secondly, there's no way to stop someone from being able to detect if a
realm name is valid or not. Pretty much every endpoint the server has can
tell you that. I assume you're not seriously expecting us to provide some
sort of fake realm where there is none?
On Tue, Aug 15, 2017 at 1:19 PM Bill Burke <bburke(a)redhat.com> wrote:
> The idea of that URL is to expose public information about the realm,
> i.e. public cert/key and public endpoint urls. If this information is
> not being used and we have other mechanisms in place, then yeah, remove
it.
>
> IMO, the jira you reference is unrelated. Its about shutting down the
> admin console/API. As far as that goes, it would be cool to split up
> keycloak into separate subsystems:
>
> * backend (required)
> * admin api/console
> * account service
> * authentication/brokering/token endpoints
>
> Even have the admin api/console be exposed from a different bind
> address/port.
>
> On 8/15/17 8:00 AM, Stian Thorgersen wrote:
> > I propose we remove the realm json returned at "/auth/realms/<realm
> name>"
> > and just return an empty page
> >
> > * It can end-up being visible to end-users - we should rather have a
> realm
> > welcome page / SSO landing page here
> > * It's not used by anything AFAIK
> > * From time to time people complain about it (
> > https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's
more
> > similar issues reported)
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:40 a.m.
On 08/15/2017 05:00 AM, Stian Thorgersen wrote:
I propose we remove the realm json returned at
"/auth/realms/<realm name>"
and just return an empty page
* It can end-up being visible to end-users - we should rather have a realm
welcome page / SSO landing page here
What is wrong with exposing this json to
users?
* It's not used by anything AFAIK
I'm not sure if this endpoint is documented but it can be used by
users/clients. For example we use this endpoint to fetch the public key
of the realm in openshift.io plus for simple health check. Should
something else be used instead?
* From time to time people complain about it (
https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more
similar issues reported)
It seems that I don't have access to this issue. What
kind of problems
this endpoint can cause?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:46 p.m.
On 16 August 2017 at 15:40, Alexey Kazakov <alkazako(a)redhat.com> wrote:
On 08/15/2017 05:00 AM, Stian Thorgersen wrote:
> I propose we remove the realm json returned at "/auth/realms/<realm
name>"
> and just return an empty page
>
> * It can end-up being visible to end-users - we should rather have a
realm
> welcome page / SSO landing page here
What is wrong with exposing this json to users?
Nothing much really. There's no details there that are sensitive nor can't
easily be found out regardless. It doesn't look good if a end-user happens
to go to this URL though and is shown some JSON file rather than a HTML
page.
> * It's not used by anything AFAIK
I'm not sure if this endpoint is documented but it can be used by
users/clients. For example we use this endpoint to fetch the public key
of the realm in openshift.io plus for simple health check. Should
something else be used instead?
For public keys use:
/auth/realms/<realm name>/.well-known/openid-configuration
That's what our adapters use and it's a OIDC standard endpoint
> * From time to time people complain about it (
> https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more
> similar issues reported)
It seems that I don't have access to this issue. What kind of problems
this endpoint can cause?
Folks claim it's a security issue. I disagree with that, but it comes up
from time to time.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:45 p.m.
On 08/16/2017 09:46 PM, Stian Thorgersen wrote:
On 16 August 2017 at 15:40, Alexey Kazakov <alkazako(a)redhat.com
<mailto:alkazako@redhat.com>> wrote:
On 08/15/2017 05:00 AM, Stian Thorgersen wrote:
> I propose we remove the realm json returned at
"/auth/realms/<realm name>"
> and just return an empty page
>
> * It can end-up being visible to end-users - we should rather
have a realm
> welcome page / SSO landing page here
What is wrong with exposing this json to users?
Nothing much really. There's no details there that are sensitive nor
can't easily be found out regardless. It doesn't look good if a
end-user happens to go to this URL though and is shown some JSON file
rather than a HTML page.
> * It's not used by anything AFAIK
I'm not sure if this endpoint is documented but it can be used by
users/clients. For example we use this endpoint to fetch the
public key
of the realm in openshift.io <http://openshift.io> plus for simple
health check. Should
something else be used instead?
For public keys use:
/auth/realms/<realm name>/.well-known/openid-configuration
That's what our adapters use and it's a OIDC standard endpoint
Hm.. I don't see any public key in /auth/realms/<realm
name>/.well-known/openid-configuration
Thanks.
> * From time to time people complain about it (
> https://issues.jboss.org/browse/KEYCLOAK-5279
<https://issues.jboss.org/browse/KEYCLOAK-5279> for instance,
there's more
> similar issues reported)
It seems that I don't have access to this issue. What kind of problems
this endpoint can cause?
Folks claim it's a security issue. I disagree with that, but it comes
up from time to time.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
12:25 a.m.
My bad, been on holiday to long. It's not in there directly, but rather
then URI for the keys are specified in jwks_uri. So it'll be something like:
http://localhost:8080/auth/realms/master/protocol/openid-connect/certs
One of the main reasons you want to use this is that there can be more than
one public key permitted at any given time due to key rotation support.
On 17 August 2017 at 20:45, Alexey Kazakov <alkazako(a)redhat.com> wrote:
On 08/16/2017 09:46 PM, Stian Thorgersen wrote:
>
>
> On 16 August 2017 at 15:40, Alexey Kazakov <alkazako(a)redhat.com
> <mailto:alkazako@redhat.com>> wrote:
>
>
> On 08/15/2017 05:00 AM, Stian Thorgersen wrote:
> > I propose we remove the realm json returned at
> "/auth/realms/<realm name>"
> > and just return an empty page
> >
> > * It can end-up being visible to end-users - we should rather
> have a realm
> > welcome page / SSO landing page here
> What is wrong with exposing this json to users?
>
>
> Nothing much really. There's no details there that are sensitive nor
> can't easily be found out regardless. It doesn't look good if a
> end-user happens to go to this URL though and is shown some JSON file
> rather than a HTML page.
>
>
>
> > * It's not used by anything AFAIK
>
> I'm not sure if this endpoint is documented but it can be used by
> users/clients. For example we use this endpoint to fetch the
> public key
> of the realm in openshift.io <http://openshift.io> plus for simple
> health check. Should
> something else be used instead?
>
>
> For public keys use:
> /auth/realms/<realm name>/.well-known/openid-configuration
>
> That's what our adapters use and it's a OIDC standard endpoint
Hm.. I don't see any public key in /auth/realms/<realm
name>/.well-known/openid-configuration
Thanks.
>
>
>
> > * From time to time people complain about it (
> > https://issues.jboss.org/browse/KEYCLOAK-5279
> <https://issues.jboss.org/browse/KEYCLOAK-5279> for instance,
> there's more
> > similar issues reported)
> It seems that I don't have access to this issue. What kind of
problems
> this endpoint can cause?
>
>
> Folks claim it's a security issue. I disagree with that, but it comes
> up from time to time.
>
>
>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
1:06 p.m.
On 08/17/2017 10:25 PM, Stian Thorgersen wrote:
My bad, been on holiday to long. It's not in there directly, but
rather then URI for the keys are specified in jwks_uri. So it'll be
something like:
http://localhost:8080/auth/realms/master/protocol/openid-connect/certs
Ah, OK. That
looks good :) We will need to start using this endpoint
instead of the /auth/realms/<realm>
Thanks!
One of the main reasons you want to use this is that there can be
more
than one public key permitted at any given time due to key rotation
support.
On 17 August 2017 at 20:45, Alexey Kazakov <alkazako(a)redhat.com
<mailto:alkazako@redhat.com>> wrote:
On 08/16/2017 09:46 PM, Stian Thorgersen wrote:
>
>
> On 16 August 2017 at 15:40, Alexey Kazakov <alkazako(a)redhat.com
<mailto:alkazako@redhat.com>
> <mailto:alkazako@redhat.com <mailto:alkazako@redhat.com>>>
wrote:
>
>
> On 08/15/2017 05:00 AM, Stian Thorgersen wrote:
> > I propose we remove the realm json returned at
> "/auth/realms/<realm name>"
> > and just return an empty page
> >
> > * It can end-up being visible to end-users - we should rather
> have a realm
> > welcome page / SSO landing page here
> What is wrong with exposing this json to users?
>
>
> Nothing much really. There's no details there that are sensitive nor
> can't easily be found out regardless. It doesn't look good if a
> end-user happens to go to this URL though and is shown some JSON
file
> rather than a HTML page.
>
>
>
> > * It's not used by anything AFAIK
>
> I'm not sure if this endpoint is documented but it can be
used by
> users/clients. For example we use this endpoint to fetch the
> public key
> of the realm in openshift.io <http://openshift.io>
<http://openshift.io> plus for simple
> health check. Should
> something else be used instead?
>
>
> For public keys use:
> /auth/realms/<realm name>/.well-known/openid-configuration
>
> That's what our adapters use and it's a OIDC standard endpoint
Hm.. I don't see any public key in /auth/realms/<realm
name>/.well-known/openid-configuration
Thanks.
>
>
>
> > * From time to time people complain about it (
> > https://issues.jboss.org/browse/KEYCLOAK-5279
<https://issues.jboss.org/browse/KEYCLOAK-5279>
> <https://issues.jboss.org/browse/KEYCLOAK-5279
<https://issues.jboss.org/browse/KEYCLOAK-5279>> for instance,
> there's more
> > similar issues reported)
> It seems that I don't have access to this issue. What kind
of problems
> this endpoint can cause?
>
>
> Folks claim it's a security issue. I disagree with that, but it
comes
> up from time to time.
>
>
>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
<mailto:keycloak-dev@lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>
>
2682
days inactive
2685
days old
9 comments
4 participants
participants (4)
-
Alexey Kazakov -
Bill Burke -
John D. Ament -
Stian Thorgersen