protocol settings menu item
by Bill Burke
FYI:
I'm creating a protocol settings menu item where you can manage saml and
oidc settings. I need it right now so that I can view and manage claim
mapping types. As suggested by Pedro this will expand to define default
application settings for specific protocols as well.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
Email Internationalization
by Michael Gerber
Hi all,
How would you internationalize the emails?
I suggest that we create different templates (*.ftl) for each locale, what do you think about that?
Best
Michael
11 years
Added server version to cached resource urls
by Stian Thorgersen
Every time we release a new version we get a lot of people having problems with the admin console. Usually these are due to the browser caches old Angular templates.
I've made a change to themes so instead of a resource being loaded from:
/auth/theme/<type>/<theme name>/<resource>
It's now retrieved from:
/auth/resources/<server version>/<type>/<theme name>/<resource>
Also, I've changed index.html for the admin console to index.ftl so that I could add the resource path (including server version, admin theme name, etc.).
11 years
Modules work
by Stian Thorgersen
All dependencies are now loaded from modules. I've done some testing, but there may be issues remaining.
If you get a ClassNotFound you'll know why ;)
11 years
Re: [keycloak-dev] WildFly integration (READ ME!)
by Stan Silvert
On 2/23/2015 12:06 PM, Summers Pittman wrote:
> On 02/23/2015 11:09 AM, Stan Silvert wrote:
>> On 2/23/2015 10:42 AM, Summers Pittman wrote:
>>> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
>>>> Just to clarify we're only talking about the server, not adapters.
>>>>
>>>> For the best and most friction free experience it would be best to have a dedicated Keycloak server, not to co-locate it with your JEE apps by deploying a WAR. With that regards we are considering dropping support for deploying Keycloak as a WAR.
>>> If I'm reading you correctly instead of
>>>
>>> ~/WILDFLY_HOME/bin/startup.sh
>>> code
>>>
>>>
>>> it will be
>>>
>>>
>>> $WILDFLY_HOME/bin/startup.sh
>>> code
>>> #^@%! what broke in my auth
>>> waste 10 minutes
>>> $KEYCLOAK_HOME/bin/startup.sh
>>>
>> I don't understand. What would break?
> I start developing after a reboot and KeyCloak's server isn't
> running. The auth is broken because the server isn't running because
> I forgot to start it.
>>>
>>> By keeping it a separate war 1) I can download the thing faster and
>>> 2) I don't have to decide who to kick off of port 8080.
>> I don't think we would do anything to ban you from deploying your
>> apps in the same WildFly instance as Keycloak. Can you explain your
>> concerns in more detail?
> My reading of the original email was that the standalone server would
> be the only distribution. IE there would be no more warfile distribution.
Right. But it would be a distribution that has two modes. The modes
would be standalone mode and a mode that would allow it to join a
WildFly domain.
You could still deploy your applications to the Keycloak distribution.
But for production, that's probably not what you want.
What I don't understand is what problems it would cause. Can you
elaborate on that?
>>>
>>> Again, IF I'm reading your message correctly
>>>
>>>> That being said we still need to support embedding Keycloak in other projects. We plan to continue to support this through the mechanism UPS does, basically build-your-own auth-server.war.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Summers Pittman"<supittma(a)redhat.com>
>>>>> To:keycloak-dev@lists.jboss.org
>>>>> Sent: Friday, February 20, 2015 7:10:12 PM
>>>>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>>>>
>>>>> On 02/20/2015 12:52 PM, Stan Silvert wrote:
>>>>>> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>>>>>>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>>>>>>> No comments?!
>>>>>>> Peanut gallery chiming in; you asked for it ;)
>>>>>>>
>>>>>>> I am not a WildFly developer or administrator. So read this email as
>>>>>>> the opinions of a talented developer who loves the hell out of using
>>>>>>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>>>>>>> idea what you are talking about.
>>>>>> Thanks Summers. Very valuable feedback.
>>>>> Thanks for taking the time to explain some things I know more than I did
>>>>> this morning.
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Stian Thorgersen"<stian(a)redhat.com>
>>>>>>>>> To: "keycloak dev"<keycloak-dev(a)lists.jboss.org>
>>>>>>>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>>>>>>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> We have a few decisions to make in the not so far future. I'm away from
>>>>>>>>> Thursday, so let's have a hangout when I get back on the 17th February
>>>>>>>>> if
>>>>>>>>> that works for everyone.
>>>>>>>>>
>>>>>>>>> The list of things to discuss includes:
>>>>>>>>>
>>>>>>>>> * Drop keycloak-server.json - Should we drop our own configuration file
>>>>>>>>> and
>>>>>>>>> use DMR (standalone.xml)
>>>>>>> If on day one enabling KeyCloak in my project was any more complicated
>>>>>>> than dropping a pregenerated file into my WEB-INF directory I would have
>>>>>>> closed the project and never looked back. -1
>>>>>> We're talking about the auth server's config rather than the config for
>>>>>> your project. For projects, we want to make it even easier to the
>>>>>> point where you don't even need the json file to get a default
>>>>>> configuration.
>>>>> Ah, that makes more sense.
>>>>>>>>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>>>>>> On the one hand the wildfly CLI is black magic. On the other hand it is
>>>>>>> really well done black magic. It is very hard to do CLIs well so I
>>>>>>> would like to see the wildfly CLI be used.
>>>>>> That's the general feedback we often get from the WildFly community. I
>>>>>> agree.
>>>>>>>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>>>>>>>> admin operations over DMR? If we expose all should we deprecate the
>>>>>>>>> current
>>>>>>>>> REST endpoints?
>>>>>>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>>>>>>> read the google result for "wildfly DMR" but it quickly turned into
>>>>>>> turtles all the way down)?
>>>>>> At its core, DMR is really just a tiny single-package library where the
>>>>>> API is just 3 or 4 classes. Those classes are the "language" spoken to
>>>>>> make changes to the WildFly management model
>>>>>> (standalone.xml/domain.xml). So the question is whether we should hook
>>>>>> into the management model infrastructure to make Keycloak changes.
>>>>>>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>>>>>>> use the CLI, scripts, etc.
>>>>>> Also a typical response. Again, I agree. Thankfully, the Keycloak
>>>>>> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
>>>>>>
>>>>>> But with Keycloak, we don't yet have a CLI, so there are lots of
>>>>>> questions around whether we piggyback on WildFly CLI, which means
>>>>>> adopting DMR in some way.
>>>>>>> I haven't used the KeyCloak REST endpoints
>>>>>>> and keeping them just increases the attack surface.
>>>>>> Do you mean that keeping the REST endpoints would be a good thing or a
>>>>>> bad thing? Can we hear more from you on this topic?
>>>>> I think that if there were a WildFly way to do all of the admin tasks
>>>>> that the RESTful endpoints do now it would be good to remove the RESTful
>>>>> API to decrease the API surface to just WildFly. IE fewer things to
>>>>> worry about getting hacked and to watch for for vulnerabilities.
>>>>>>>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>>>>>>> - Full WildFly
>>>>>>>>> - Core/web WildFly
>>>>>>>>> - Overlay/installer/feature-pack to install to existing WF and EAP
>>>>>>>>> - WAR bundle
>>>>>>> How about a shell script that examines a WF install directory and does
>>>>>>> all the magic for me or aDocker container?
>>>>>>>
>>>>>>> In general I have not liked the experience of having wildfly bundled
>>>>>>> with a product. It tends to mess with other servers I have installed
>>>>>>> and be a general PITA to maintain for anything more than the most
>>>>>>> trivial of demos.
>>>>>> Good feedback.
>>>>>>>>> * How should we deal with providers, themes and keycloak-server.json in
>>>>>>>>> domain-mode
>>>>>>>>>
>>>>>>>>> * MSC all the way - We can deploy directly through the Undertow
>>>>>>>>> sub-system
>>>>>>>>> instead of deploying a WAR from the sub-system
>>>>>>> What is MSC?
>>>>>> Modular Service Container. It's the thing that lets you declare and
>>>>>> register services in WildFly. But I'm not completely sure what Stian is
>>>>>> proposing here.
>>>>>>>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>>>>>>>> auth-server and another for the adapter
>>>>>>> What are the trade offs? What will using KeyCloak look like from my POV
>>>>>>> if we split?
>>>>>> Instead of
>>>>>>
>>>>>> subsystem=keycloak/auth-server=main-auth-server
>>>>>> subsystem=keycloak/secure-deployment=foo
>>>>>>
>>>>>> you would have
>>>>>>
>>>>>> subsystem=keycloak-server/auth-server=main-auth-server
>>>>>> subsystem=keycloak-deployments/secure-deployment=foo
>>>>>>
>>>>>> Another option would be to just leave it as it is today and just hide
>>>>>> the "auth-server" resource for installations where you don't expect the
>>>>>> auth server to run.
>>>>>>
>>>>>> The answer will probably be more a function of how we want to organize
>>>>>> the code rather than how it will look to the end user.
>>>>> As a end user it sounds like both work for me.
>>>>>>>>> * Deployable to other containers - Should it be possible to deploy
>>>>>>>>> Keycloak
>>>>>>>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
>>>>>>>>> features
>>>>>>>>> in other containers (for example no client-cert)
>>>>>>> The awesomeness of WildFly has forever made web containers look
>>>>>>> insignificant to me. If Glassfish still had a community edition worth a
>>>>>>> damn I would say target it as well. I don't know how TomEE is but that
>>>>>>> may be good to support just for a "first one's free" to get people into
>>>>>>> WildFly land.
>>>>>>>
>>>>>>> I don't think Websphere or WebLogic support has ever gotten anyone
>>>>>>> excited about a project. Honestly they are the technology equivalent of
>>>>>>> taking a cold shower with grandma.
>>>>>> I could have done without that image. :-|
>>>>>>
>>>>>> But thanks again!
>>>>> YW.
>>>>>>>>> Please add any other relevant topics.
>>>>>>>>>
>>>>>>>>> Next big discussion I want to have is about distribution of adapters,
>>>>>>>>> but
>>>>>>>>> let's do one at a 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
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> --
>>>>> Summers Pittman
>>>>>>> Phone:404 941 4698
>>>>>>> Java is my crack.
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>> --
>>> Summers Pittman
>>> >>Phone:404 941 4698
>>> >>Java is my crack.
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
11 years
Re: Internationalization support (KEYCLOAK-301)
by Michael Gerber
Am 24. Februar 2015 um 09:47 schrieb Marek Posolda <mposolda(a)redhat.com>:
On 24.2.2015 07:40, Stian Thorgersen wrote:
----- Original Message -----
From: "Michael Gerber" <gerbermichi(a)me.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "Marek Posolda" <mposolda(a)redhat.com>, "Stan Silvert" <ssilvert(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Tuesday, February 24, 2015 7:37:10 AM
Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
Am 24. Februar 2015 um 07:26 schrieb Stian Thorgersen <stian(a)redhat.com>:
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Michael Gerber" <gerbermichi(a)me.com>, "Stan Silvert"
<ssilvert(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Monday, February 23, 2015 6:48:00 PM
Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
Will the order be configurable? For example admin may want to configure
realm locale (5) and wants users to use this one instead of
Accept-Language header (4) ?
Is that really required?
A configurable order doesn't make sense for me, because you shouldn't change
step 1, 2, 3 and 5.
The only possible solution would be to make step 4 (Accept-Language)
optional. So, the admin can disable it in the admin console.
Yes, that was what I was thinking, swapping 4 and 5 is the same as disabling Accept-Language. I can't see why anyone would want to do that though.
Maybe just because he wants to enforce showing login page in "tested"
language like English ? Accept-Language can contain anything in it, so
it may contain language, which is "partially" supported by Keycloak (not
all labels and messages properly translated) and it may lead to the
unproper login page with some labels in english and some in the second
language, which may not look good.
But I don't know, maybe the use-case is really just theoretic. I agree
that other changes in order instead of removing Accept-Language are
likely not needed.
Marek
The admin can configure the supported locales, so he can add only english, if he wants to support only english.
Marek
On 23.2.2015 18:40, Michael Gerber wrote:
The algorithm to determine the correct locale is like that:
1. Locale cookie
2. User profile (UserModel.attribute)
3. ui_locales query parameter
4. Accept-Language http header
5. Default realm locale
The login page has also a dropdown with all available locales. The selected
value will be stored in the locale cookie.
Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert(a)redhat.com>:
On 2/23/2015 12:00 PM, Bill Burke wrote:
What's the best practice for choosing local?
As I understand it, the thing to do is to use the accept-language header
as a starting point. If it's the only thing you have to go on then use
it.
But I think we should definitely have a UserModel.attribute that is
settable by the user.
Also, we have talked about building an "application switcher" component
that developers can include in their apps. That app switcher should
include a dropdown to switch locale as well as one for switching the
application.
* User-Agent header?
* From a login hint? I think OIDC has something like this (but what
about SAML)?
* Should we store this information somewhere (cookie,
UserModel.attribute, etc..)
On 2/23/2015 11:53 AM, Michael Gerber wrote:
Hi all,
I started to work on the internationalization support
(https://issues.jboss.org/browse/KEYCLOAK-301).
I’ve already implemented the realm config in the admin console. I’ve put
it into the „Theme Setting“ (see screenshot)
I added the possibility to enable internationalization, add supported
locales and a select a default locale.
Now I’d like to implement the logic which choose the correct locale.
Therefore I need the http header, cookie, query parameter, realm and
user.
The LoginFormsProvider and AccountProvider have all this information
apart from the http header and the cookie.
So I thought I could replace the UriInfo with the HttpRequest, but that
doesn’t work, because I can not access the UriInfo through the
HttpRequest (java.lang.NoSuchMethodError:
org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
So, I will add the HttpHeader to the LoginFormsProvider
and AccountProvider, or does anyone have a better idea?
@Bill
How do you plan to store the claim „locale“ on a user? Will it be
accessible through the UserModel interface?
Best
Michael
_______________________________________________
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11 years
Simple mode?
by Bill Burke
Conversations with jboss.org guys got me thinking. Should we have a
"simple mode" for Keycloak where there is no concept of a client,
application, or roles? In this case,
* applications don't need session mgmt or single log out
* All applications are hosted under the same domain i.e *.jboss.org
(issues.jboss.org, forums.jboss.org, etc...)
* applications just need to know if 1) the user is logged in, 2) the
username/id
So, "simple mode" would be:
* No applications/client panel
* No role pages anywhere
* Realm would have a global javascript referable cookie that contained
basic information (userid, username, full name). The domain and path
would be configurable from admin console
* Realm would have a list of valid redirect URI patterns.
* Realm would have a default redirect page for unsolicited logins.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
Re: Internationalization support (KEYCLOAK-301)
by Michael Gerber
Am 24. Februar 2015 um 07:26 schrieb Stian Thorgersen <stian(a)redhat.com>:
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Michael Gerber" <gerbermichi(a)me.com>, "Stan Silvert" <ssilvert(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Monday, February 23, 2015 6:48:00 PM
Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
Will the order be configurable? For example admin may want to configure
realm locale (5) and wants users to use this one instead of
Accept-Language header (4) ?
Is that really required?
A configurable order doesn't make sense for me, because you shouldn't change step 1, 2, 3 and 5.
The only possible solution would be to make step 4 (Accept-Language) optional. So, the admin can disable it in the admin console.
Marek
On 23.2.2015 18:40, Michael Gerber wrote:
> The algorithm to determine the correct locale is like that:
> 1. Locale cookie
> 2. User profile (UserModel.attribute)
> 3. ui_locales query parameter
> 4. Accept-Language http header
> 5. Default realm locale
>
> The login page has also a dropdown with all available locales. The selected
> value will be stored in the locale cookie.
>> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert(a)redhat.com>:
>>
>> On 2/23/2015 12:00 PM, Bill Burke wrote:
>>> What's the best practice for choosing local?
>> As I understand it, the thing to do is to use the accept-language header
>> as a starting point. If it's the only thing you have to go on then use
>> it.
>>
>> But I think we should definitely have a UserModel.attribute that is
>> settable by the user.
>>
>> Also, we have talked about building an "application switcher" component
>> that developers can include in their apps. That app switcher should
>> include a dropdown to switch locale as well as one for switching the
>> application.
>>> * User-Agent header?
>>> * From a login hint? I think OIDC has something like this (but what
>>> about SAML)?
>>> * Should we store this information somewhere (cookie,
>>> UserModel.attribute, etc..)
>>>
>>>
>>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
>>>> Hi all,
>>>>
>>>> I started to work on the internationalization support
>>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
>>>>
>>>> I’ve already implemented the realm config in the admin console. I’ve put
>>>> it into the „Theme Setting“ (see screenshot)
>>>> I added the possibility to enable internationalization, add supported
>>>> locales and a select a default locale.
>>>>
>>>> Now I’d like to implement the logic which choose the correct locale.
>>>> Therefore I need the http header, cookie, query parameter, realm and
>>>> user.
>>>> The LoginFormsProvider and AccountProvider have all this information
>>>> apart from the http header and the cookie.
>>>> So I thought I could replace the UriInfo with the HttpRequest, but that
>>>> doesn’t work, because I can not access the UriInfo through the
>>>> HttpRequest (java.lang.NoSuchMethodError:
>>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
>>>> So, I will add the HttpHeader to the LoginFormsProvider
>>>> and AccountProvider, or does anyone have a better idea?
>>>>
>>>> @Bill
>>>> How do you plan to store the claim „locale“ on a user? Will it be
>>>> accessible through the UserModel interface?
>>>>
>>>> Best
>>>> Michael
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11 years
