From francis.pouatcha at adorsys.com Fri Jul 1 01:48:41 2016 From: francis.pouatcha at adorsys.com (Francis Pouatcha) Date: Fri, 1 Jul 2016 07:48:41 +0200 Subject: [keycloak-dev] How to setup a maven project generating jar containing authentication providers in a debug mode in eclipse In-Reply-To: References: Message-ID: Rashmi, follow these instructions to have keycloack debug accessible from eclipse: 1- Simple web application User a simple HelloServlet to try out the debugging process before applying you experience to wildfly. 1- Wildfly and eclipse Like Thomas mentioned, Make sure you active the debug property while starting wildfly. This is independent of keycloak, as keycloak is just another web application running on wildfly. So make sure you have a simple webapp running in wildfly standalone so you can get used to the debugging process. 2- Wildfly in a docker container Take your simple web application and wildfly into a docker container and try following: a) Make sure you start wildfly in the container in debug mode. Not matter how you manage the docker containers in your development environment, you will have to expose their ports so you can reach the container from and outside the docker host. "Exposing the port means mapping the defined wildfly ports to some other ports on the docker host. If you are using docker-composer you have to try something like: ports:\ - "8080:8080"\ - "8787:8787". In this case see the docker-compose reference for details. 3- Accessing the docker container Once you wildfly docker container is startet in debug mode, make sure you can access you HelloServlet from a web browser on the same machine on which you have your eclipse installed. If this works, use the same hostname or ip to replace "localhost" in you eclipse debugging config. Generally this will default to: 192.168.99.100:8787. You did it right, you will be able to stop on the breakpoint inside your HelloServlet. 4- Keycloak Repeat the same procedure with your custom authenticator. Do not forget to download the keycloak sources and include them in your the source path so you can navigate and set break points. Best regards Mit freundlichen Gr??en Cordialement Francis Pouatcha Founder and Technical Lead Group Adorsys LinkedIn: http://www.linkedin.com/pub/francis-pouatcha/8/35a/542 adorsys GmbH & Co. KG, Germany: http://www.youtube.com/watch?v=rVRkFGUNexo&authuser=0 Adorsys S.A., Cameroon: "African Software Competence Center" Open https://github.com/adorsys Cell USA: +1 770 329 7026 Cell Germany: +49 172 18 16 074 Cell Cameroon: +237 51 74 71 99 On Fri, Jul 1, 2016 at 2:39 AM, Rashmi Singh wrote: > Thanks Thomas for your reply. I have a few questions on your response. I > am still very new to docker, so please bear with me. > when you say I can set env variables in docker container, would this be > sufficient? > > First connect to the docker container as: > > docker exec -i -t keycloak bash > Then, once I am in the container, I run the following to set env variables? > > set DEBUG_MODE=true > set DEBUG_PORT=8787 > exit > Then, restart the container as: > docker restart keycloak (keycloak is the name of my container) > Also, how can I make sure that the env variable got correctly set in the > docker container? From inside the container, if I run the command "env", > should it list these new env variables if they are added successfully? > > Then, when you say "......default on port 8787 which you need to expose > on your docker container or use the container interface...", what exactly > do you mean? Do you mean some sort of port forwarding? Could you tell me w > tohat exactly I need to do with my existing container named as "keycloak" > > Then, on eclipse, where you mentioned the settings for the Debug > configurations, what should be the hostname there? would it be localhost? > or the default machine IP of docker which is 192.168.99.100? Or it should > be something else? > > > > On Thu, Jun 30, 2016 at 6:29 PM, Thomas Darimont < > thomas.darimont at googlemail.com> wrote: > >> Hello, >> >> you could add -debug flag to the standalone.sh command-line or define the >> following env variables in your docker container: >> set DEBUG_MODE=true >> set DEBUG_PORT=8787 >> >> this will start keycloak with remote debugging enabled by default on port >> 8787 which you need to expose on your docker container or use the container >> interface... >> >> you can then connect to the keycloak instance inside the docker container >> via the remote debugger from your IDE. >> For eclipse just go to "Debug configurations..." -> Remote Java >> Application -> select your project with the custom authenticator -> adjust >> hostname and port and click "debug". >> >> Cheers, >> Thomas >> >> 2016-07-01 0:26 GMT+02:00 Rashmi Singh : >> >>> We have a Maven project setup on Eclipse that uses some keycloak >>> features and we generate a jar that contains our AuthenticationProvider >>> classes etc. >>> We use docker for the deployment. We basically run a jboss/keycloak >>> image there >>> We have a shell script that has a bunch of commands to copy our project >>> jars from local to the keycloak image on docker container like: >>> >>> docker cp /customauthenticator-1.0.0-SNAPSHOT.jar >>> keycloak:/home/modules/xxx.yyy.zz.keycloak.customizations >>> .... >>> docker restart keycloak >>> >>> Running this shell script deploys everything on keycloak on docker. >>> And so far we are just putting logs throughout our code to debug issues. >>> We want to be able to setup a debugging environment on our eclipse. I am >>> not sure how to achieve this when we use keycloak. Because, here we >>> basically build our modules or authenticator jars etc and copy them to >>> keycloak directories. So, it's not a standalone project war file that we >>> are directly deploying to app server as such. So, then how do we put our >>> maven project (creating jars etc) in a debug mode in eclipse? Is it >>> possible? How? >>> >>> _______________________________________________ >>> 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/20160701/55847970/attachment.html From sthorger at redhat.com Fri Jul 1 02:43:56 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 08:43:56 +0200 Subject: [keycloak-dev] Backward compatibility of server and adapters In-Reply-To: <57752604.9070103@redhat.com> References: <57752604.9070103@redhat.com> Message-ID: I'm not convinced about that approach. We'll end up having to test and maintain this in the long run. How about a staged approach instead: * Keycloak 2.1 & RH-SSO 7.0.1 - add scope=openid, also add mention in release not and migration guide that the ID token will soon not be included anymore * Keycloak 2.3 & RH-SSO 7.1 - stop sending ID token if scope is not included On 30 June 2016 at 16:00, Marek Posolda wrote: > I am thinking whether to add configuration switch in admin console per > client, where you can define what is the adapter version the particular > client is using. In that case, some behaviour can be different/backwards > compatible. > > Example: For new clients, we will include IDToken just if they use > "scope=openid" . However for clients with adapter "1.9" or older, the > IDToken will be included even if "scope=openid" is not used. > > WDYT? > Marek > _______________________________________________ > 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/20160701/07b195a1/attachment.html From sthorger at redhat.com Fri Jul 1 02:58:45 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 08:58:45 +0200 Subject: [keycloak-dev] Some OIDC JIRAs to fix? In-Reply-To: <57752BBD.2080107@redhat.com> References: <57752BBD.2080107@redhat.com> Message-ID: On 30 June 2016 at 16:25, Marek Posolda wrote: > I am adding some OIDC specs JIRAs with possibility how to fix them. I am > including those, which will be easy to fix and I can look into them later > today or tomorrow before PTO : > > https://issues.jboss.org/browse/KEYCLOAK-3189 - Add 'typ' to JWT header > +1 > > https://issues.jboss.org/browse/KEYCLOAK-3190 - Add 'kid' to JWT header > +1 > > https://issues.jboss.org/browse/KEYCLOAK-3217 - UserInfo endpoint not > accessible by POST request secured with Bearer header > +1 > https://issues.jboss.org/browse/KEYCLOAK-3147 - OpenID Connect auth > request redirect_uri behaviour not according to spec > +1 To just require redirect_uri in either case We need separate JIRAs for scope=openid and another one for removal of ID token when scope=openid isn't used > > https://issues.jboss.org/browse/KEYCLOAK-3222 - WellKnown endpoint > doesn't return supported types of client authentication > +1 > https://issues.jboss.org/browse/KEYCLOAK-3219 - WellKnown endpoint > doesn't support claims_supported > Maybe this one isn't so straightforward due to protocol mappers? > > > All of those are quite straightforward and easy to fix IMO. > > > Besides that, there are those 2, which I first rather want to confirm what > exactly to do: > > - https://issues.jboss.org/browse/KEYCLOAK-3221 Tokens not invalidated if > an attempt to reuse code is made > > We have just single-use code (which is good), however OAuth2 specs > recommends to invalidate existing tokens if an attempt to reuse code is > done. And one OIDC test is in WARNING state because of it (it tries to > access UserInfo endpoint with the accessToken issued with the reused code). > > I can see 2 possibilities to fix: > a) Invalidate just single clientSession where "code" attempt reuse was made > b) Logout whole userSession > > It looks to me that (a) is sufficient solution. The potential issue with > (b) is, that if attacker can steal code, it gives him the possibility to > trigger global logout of user from all apps. WDYT? > I think option (a) is the correct approach. I interpret the spec to state that tokens associated with the specific code should be invalidated. Option (b) seems a bit over the top and not necessary I also wonder if there's non-malicious situations where an application could try to exchange a code twice, for example after a timeout or an automated connection retry? > > > - https://issues.jboss.org/browse/KEYCLOAK-3218 Support for "max_age" in > AuthorizationEndpoint and "auth_time" claim on IDToken > > The possibility to implement is : > - Add new note AUTH_TIME to UserSessionModel. It will be time when > authentication of user was fully finished (including requiredActions). > Session note is used just so we don't need to change the model ;) > - If "max_age" parameter was requested, the "auth_time" will be added to > IDToken (or I will re-check specs if we should rather always add it to > IDToken) > - I am also thinking about adding hook to CookieAuthenticator, so that if > max_age parameter was used and userSession authTime is too "old", the > CookieAuthenticator will be ignored and user will need to re-authenticate > with other authenticators (username/password form etc). Then authTime will > be updated on userSession once authentication is finished. > +1 Sounds good > > WDYT? > > That will leave us with bigger things for OIDC Basic certification ( scope > parameter support, possibly 'claims' param support and 'acr' support). > > Marek > > _______________________________________________ > 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/20160701/e33c35e7/attachment-0001.html From sthorger at redhat.com Fri Jul 1 03:00:55 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 09:00:55 +0200 Subject: [keycloak-dev] Client Registration CLI tool In-Reply-To: References: <20160629194934.GB4141@abstractj.org> <20160630051532.GA29127@abstractj.org> <20160630060811.GA3893@abstractj.org> Message-ID: On 30 June 2016 at 20:06, Bruno Oliveira wrote: > Sorry about the duplicated e-mail. > > On Wed, Jun 29, 2016, 11:21 PM Stian Thorgersen > wrote: > >> On 30 June 2016 at 08:08, Bruno Oliveira wrote: >> >>> What I suggested was based on what I saw at our current proposal: >>> >>> $ kcreg login -r master -u manage-client >>> Server to connect to (http://localhost:8080/auth): >>> Password: >>> >>> If you want to automate it for example in a shell script, unless I'm >>> mistaken, you have to provide user's password or obtain initial access >>> token through console. If we're assuming that's the default >>> flow for automated scripts should be obtaining an initial access token >>> from console first, that's fine. >>> >> >> Yes, the password is just for manual use and wouldn't be cached or >> anything like that. >> >> >>> >>> Flow for encryption: >>> >>> 1. Admin client retrieve the public key from the server >>> 2. Admin client encrypt's whatever data is sensitive >>> 3. Server decrypt's it >>> >> >> Isn't that only going to hide the password? The encrypted password could >> still be used as the server would accept/decrypt it. >> > > Not only passwords, but username as well. Into other words any sensitive > data. > > I don't follow you on this. The server will decrypt and validate those > credentials. > > Anyways, this is just an idea, if it doesn't worth it, never mind. > I don't think it's needed in this case as we won't be storing username/passwords. I'd still like to understand/talk about what you are proposing though, but we should have that discussion in a separate thread ;) > > > >> >>> >>> On 2016-06-30, Stian Thorgersen wrote: >>> > I can't see why we should consider it though: >>> > >>> > a) We have service account support, initial access tokens, offline >>> tokens, >>> > etc.. All designed so credentials don't need to be stored. Using a user >>> > account directly is horrible as not only are you potentially exposing >>> the >>> > credentials, you're also giving all permissions of the user to the >>> > automation. Using tokens or service account you can limit what >>> permissions >>> > the automation has. >>> > b) If the credentials are encrypted, you'll also need to unlock the >>> > vault/encrypted file. How would you suggest we do that? I can't see the >>> > full flow here. >>> > >>> > On 30 June 2016 at 07:15, Bruno Oliveira wrote: >>> > >>> > > Yes, the encrypted data goes into public repository with >>> .travis.yaml file. >>> > > Only the Travis server is able to decrypt such data and validate >>> it[1][2]. >>> > > >>> > > Like I mentioned, not a blocker, but maybe something to take into >>> > > consideration. >>> > > >>> > > [1] - >>> > > >>> https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example >>> > > [2] - >>> https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32 >>> > > >>> > > On 2016-06-30, Stian Thorgersen wrote: >>> > > > The encryption support in Travis isn't that so you can encrypt >>> sensitive >>> > > > details that goes into .travis.yaml which is public through the >>> repo? >>> > > > >>> > > > On 30 June 2016 at 06:52, Stian Thorgersen >>> wrote: >>> > > > >>> > > > > I don't see the need for that. For the client registration CLI >>> we will >>> > > > > support initial access tokens as well as service accounts with >>> > > pub/priv key >>> > > > > authentication. For admin cli we'll support service accounts. No >>> one >>> > > should >>> > > > > be using username/password combined with automated jobs. >>> > > > > >>> > > > > On 29 June 2016 at 21:49, Bruno Oliveira >>> wrote: >>> > > > > >>> > > > >> I'm not sure if it's part of the scope for now. But >>> > > > >> thinking about situations where you have to automate jobs plus >>> provide >>> > > > >> credentials without exposing them. >>> > > > >> >>> > > > >> My suggestion, even if it's not part of the scope for now is to >>> > > encrypt >>> > > > >> it, >>> > > > >> like travis does[1]. I know that our plan is to deal of access >>> token, >>> > > > >> but would be nice to not expose credentials not even a single >>> time. >>> > > > >> >>> > > > >> >>> > > > >> [1] - https://docs.travis-ci.com/user/encryption-keys/ >>> > > > >> >>> > > > >> On 2016-06-29, Stian Thorgersen wrote: >>> > > > >> > On 28 June 2016 at 11:40, Marko Strukelj >> > >>> > > wrote: >>> > > > >> > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen < >>> > > > >> sthorger at redhat.com> >>> > > > >> > > wrote: >>> > > > >> > > >>> > > > >> > >> >>> > > > >> > >> >>> > > > >> > >> On 27 June 2016 at 21:26, John Dennis >>> > > wrote: >>> > > > >> > >> >>> > > > >> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote: >>> > > > >> > >>> > I've started work on Client Registration CLI tool. As a >>> first >>> > > > >> step, >>> > > > >> > >>> here >>> > > > >> > >>> > is a design document describing how I imagine the tool >>> would >>> > > be >>> > > > >> used. >>> > > > >> > >>> > >>> > > > >> > >>> > >>> > > > >> > >>> > >>> > > > >> > >>> >>> > > > >> >>> > > >>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing >>> > > > >> > >>> > >>> > > > >> > >>> > >>> > > > >> > >>> > I'll use this document as a spec / guide as I implement >>> the >>> > > client >>> > > > >> > >>> tool. >>> > > > >> > >>> > >>> > > > >> > >>> > Within days I'll also send a link to initial ideas for >>> Admin >>> > > > >> Client >>> > > > >> > >>> tool >>> > > > >> > >>> > which in principle should allow administrator to >>> configure >>> > > > >> everything >>> > > > >> > >>> > that can otherwise be done through Admin Console. >>> > > > >> > >>> > >>> > > > >> > >>> > Any feedback welcome. >>> > > > >> > >>> >>> > > > >> > >>> FWIW we've already written a client registration tool for >>> > > Keycloak. >>> > > > >> At >>> > > > >> > >>> the moment it is specifically targeted for SAML clients >>> (SP, >>> > > Service >>> > > > >> > >>> Provider) in Apache HTTPD but we have plans to extend it >>> to >>> > > OIDC. >>> > > > >> > >>> >>> > > > >> > >>> It is currently in Fedora and will also ship in OSP. >>> > > > >> > >>> >>> > > > >> > >>> It is hosted here: >>> > > > >> > >>> https://github.com/jdennis/keycloak-httpd-client-install >>> > > > >> > >>> >>> > > > >> > >>> The man page for it (formatted for HTML) can be found >>> here: >>> > > > >> > >>> >>> > > > >> >>> > > >>> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html >>> > > > >> > >>> >>> > > > >> > >>> The man page discusses 3 different ways you can >>> authenticate >>> > > and 2 >>> > > > >> > >>> different ways client registration can be performed. >>> > > > >> > >>> >>> > > > >> > >>> I have a lot of experience with Keycloak client >>> registration >>> > > tools >>> > > > >> and >>> > > > >> > >>> have worked through many issues, I'm happy to share my >>> > > experience. >>> > > > >> > >>> >>> > > > >> > >>> Here are some thoughts/issues you may want to take into >>> account: >>> > > > >> > >>> >>> > > > >> > >>> * The tool must be capable of running without >>> interactivity as >>> > > part >>> > > > >> of a >>> > > > >> > >>> scripted installation task. >>> > > > >> > >>> >>> > > > >> > >>> * It should not depend on a home directory being >>> available. >>> > > > >> > >>> >>> > > > >> > >>> * If a home directory is utilized how will you >>> disambiguate any >>> > > > >> stored >>> > > > >> > >>> state belonging to a script that is run by different >>> processes >>> > > but >>> > > > >> under >>> > > > >> > >>> the same user (possibly simultaneously)? To clarify, many >>> > > install >>> > > > >> tools >>> > > > >> > >>> run as the root user or some other admin user. Each >>> invocation >>> > > of >>> > > > >> these >>> > > > >> > >>> install tools can be run with entirely different >>> parameters and >>> > > may >>> > > > >> > >>> execute either in parallel or partially overlapping in >>> time. >>> > > > >> > >>> >>> > > > >> > >> >>> > > > >> > > Maybe I should have included this link in the design >>> document to >>> > > make >>> > > > >> it >>> > > > >> > > clear to everyone what Client Registration this tool is for: >>> > > > >> > > >>> > > > >> >>> > > >>> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html >>> > > > >> > > >>> > > > >> > > It's a REST API defined by specs, and is separate from >>> Admin REST >>> > > API. >>> > > > >> > > >>> > > > >> > > About using home directory, the way I see it - you either a) >>> > > specify >>> > > > >> all >>> > > > >> > > the state when executing a command, or b) you have a >>> mechanism >>> > > that >>> > > > >> allows >>> > > > >> > > the concept of 'session' between command invocations. >>> > > > >> > > >>> > > > >> > > If you use the first approach (a) then on each invocation >>> of the >>> > > > >> command >>> > > > >> > > you have to specify either username:password, or a token. >>> The >>> > > client >>> > > > >> > > registration specification defines workflow for Initial >>> Access >>> > > > >> Tokens, and >>> > > > >> > > Registration Access Tokens, which require to automatically >>> > > intercept a >>> > > > >> > > newly issued token after each CRUD operation, and save it >>> for any >>> > > > >> > > subsequent operation on the same client resource. I can't >>> see how >>> > > this >>> > > > >> > > could be achieved by using the first approach. >>> > > > >> > > >>> > > > >> > > For the second approach (b) you need a way to communicate >>> > > 'session' >>> > > > >> state. >>> > > > >> > > The state we are saving are just tokens associated with >>> current >>> > > user >>> > > > >> or >>> > > > >> > > specific clients, or specific grants. Looks to me that if >>> multiple >>> > > > >> parallel >>> > > > >> > > sessions are in collision about these tokens then the cli >>> tool >>> > > itself >>> > > > >> might >>> > > > >> > > be used the wrong way. Namely, once the client >>> authenticates with >>> > > a >>> > > > >> login, >>> > > > >> > > access token and refresh token are cached. Multiple client >>> > > instances >>> > > > >> can >>> > > > >> > > use the same access token, and the same refresh token. A >>> thing to >>> > > > >> maybe be >>> > > > >> > > careful about is just properly locking the file when making >>> > > changes >>> > > > >> to it. >>> > > > >> > > For initial access token you have to explicitly add it, and >>> > > assign it >>> > > > >> an >>> > > > >> > > alias - you can use any random value there if you want. For >>> > > > >> registration >>> > > > >> > > access token they are automatically associated with initial >>> token >>> > > > >> they were >>> > > > >> > > initiated from - again there should be no collision. >>> > > > >> > > >>> > > > >> > >>> > > > >> > I like the option to have two approaches as there are two >>> use-cases. >>> > > > >> One is >>> > > > >> > manually registering for example during development or when >>> manually >>> > > > >> > configuring an application to use Keycloak. Another is >>> scripted. >>> > > Even >>> > > > >> for >>> > > > >> > scripted you may quite likely want to just add service account >>> > > > >> credentials >>> > > > >> > or initial access token directly to ~/.keycloak/ rather than >>> pass >>> > > these >>> > > > >> to >>> > > > >> > the commands. >>> > > > >> > >>> > > > >> > Registration access tokens are associated with a client, not >>> an >>> > > initial >>> > > > >> > access token. Also, remember the registration access token is >>> > > changed on >>> > > > >> > updates. >>> > > > >> > >>> > > > >> > >>> > > > >> > > >>> > > > >> > > What alternative mechanism would you suggest for storing >>> 'session' >>> > > > >> info? >>> > > > >> > > We want to support Windows as well so it can't be Unix / >>> Bash >>> > > > >> specific. >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > >> >>> > > > >> > >>> * The tool should be idempotent. >>> > > > >> > >>> >>> > > > >> > >>> * You suggest storing tokens in a cache, how do you plan >>> on >>> > > > >> handling the >>> > > > >> > >>> case where a token expires before all operations are >>> complete? >>> > > > >> > >>> >>> > > > >> > >>> * We also initially took the approach of caching tokens >>> but >>> > > > >> discovered >>> > > > >> > >>> the complexity did not justify the minimal cost of >>> obtaining a >>> > > new >>> > > > >> token >>> > > > >> > >>> for each invocation. This greatly simplified the code >>> with very >>> > > > >> little >>> > > > >> > >>> performance impact. >>> > > > >> > >>> >>> > > > >> > >>> * You do not mention what type of client you're >>> registering. I'm >>> > > > >> > >>> assuming it's OpenID but SAML clients (SP) are equally >>> > > important. >>> > > > >> The >>> > > > >> > >>> tool must be able to handle both. >>> > > > >> > >>> >>> > > > >> > >> >>> > > > >> > >> Marko is probably referring to the Keycloak client >>> > > representation, >>> > > > >> which >>> > > > >> > >> can be either OpenID or SAML. However, we also need to >>> support >>> > > OpenID >>> > > > >> > >> Connect client descriptions as well as SAML entity >>> descriptors as >>> > > > >> both are >>> > > > >> > >> supported by client reg services. >>> > > > >> > >> >>> > > > >> > > >>> > > > >> > > The CLI needs to know which of the client registration >>> providers >>> > > (REST >>> > > > >> > > endpoints) to use - there are four as described in the >>> Client >>> > > > >> Registration >>> > > > >> > > documentation ( >>> > > > >> > > >>> > > > >> >>> > > >>> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html >>> > > > >> > > ) >>> > > > >> > > >>> > > > >> > > Ideally the input format of the file could be recognised as >>> only >>> > > > >> > > appropriate for one of these providers, and the correct >>> provider >>> > > then >>> > > > >> > > automatically used. But maybe we need a way to explicitly >>> tell the >>> > > > >> tool >>> > > > >> > > what provider to use. For example: >>> > > > >> > > >>> > > > >> > > kc new --type default --name test-app --enabled true >>> --base-url >>> > > > >> > > http://localhost:8480/test-app --redirect-uri ' >>> > > > >> > > http://localhost:8480/test-app/*' --admin-url >>> > > > >> > > http://localhost:8480/test-app/logout --secret password | >>> kc >>> > > create >>> > > > >> > > --type default -f - >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > Having to set --type for both creating a description (kc >>> new), and >>> > > > >> > > pushing it to the server (kc create) is not ideal. >>> > > > >> > > >>> > > > >> > >>> > > > >> > We can detect the difference between Keycloak client rep, >>> SAML and >>> > > OIDC >>> > > > >> > json that's pretty trivial and we should do that. However, >>> there >>> > > needs >>> > > > >> to >>> > > > >> > be a way to specify the provider as well as there could be >>> custom >>> > > > >> providers >>> > > > >> > added. >>> > > > >> > >>> > > > >> > For getting the client it should by default return Keycloak >>> client >>> > > > >> > representation, but we need an option to be able to specify >>> the >>> > > > >> provider so >>> > > > >> > it can return the client installation file instead. >>> > > > >> > >>> > > > >> > With regards to creating by passing arguments rather than a >>> file >>> > > that >>> > > > >> > should only support client representation files. >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > >> >>> > > > >> > >> >>> > > > >> > >>> >>> > > > >> > >>> * I don't see anything in your document on how to specify >>> the >>> > > SAML >>> > > > >> > >>> metadata. >>> > > > >> > >>> >>> > > > >> > >> >>> > > > >> > > Instead of piping in my-client.json, you would pipe in >>> > > > >> my-client-saml.xml, >>> > > > >> > > possibly requiring an extra --type specifier as described >>> above. >>> > > > >> > > >>> > > > >> > > >>> > > > >> > >> >>> > > > >> > >>> * I don't see anything in your document on how the user >>> > > modifies the >>> > > > >> > >>> client. It appears as if you are retrieving a >>> > > ClientRepresentation >>> > > > >> JSON >>> > > > >> > >>> document and expecting the user to edit it in a text >>> editor >>> > > which >>> > > > >> will >>> > > > >> > >>> then be sent back. That won't work for non-interactive >>> > > installs. It >>> > > > >> also >>> > > > >> > >>> presumes the user knows how to read and modify the JSON. >>> > > > >> > >>> >>> > > > >> > >> >>> > > > >> > >> It would be nice to be able to set specific fields without >>> > > having to >>> > > > >> > >> modify JSON. We discussed that for the Admin CLI, but we >>> should >>> > > > >> probably >>> > > > >> > >> also add it to the client reg CLI >>> > > > >> > >> >>> > > > >> > > >>> > > > >> > > It would be very valuable to see some of the usecases, what >>> kind >>> > > of >>> > > > >> > > changes people do on existing clients. >>> > > > >> > > >>> > > > >> > >>> > > > >> > We should support anything that is in client representation. >>> It >>> > > should >>> > > > >> just >>> > > > >> > be a generic way to change json fields. For example: >>> > > > >> > >>> > > > >> > # kcreg update --set enabled=false --set baseUrl= >>> > > > >> > http://new-url/myapp --remove rootUrl >>> > > > >> > >>> > > > >> > This would get the KC client rep, change the corresponding >>> fields >>> > > and >>> > > > >> send >>> > > > >> > it back. >>> > > > >> > >>> > > > >> > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > >> >>> > > > >> > >> >>> > > > >> > >>> >>> > > > >> > >>> * Keycloak currently has a few problems with client >>> > > registration and >>> > > > >> > >>> it's necessary to modify the client before it will work >>> > > correctly. >>> > > > >> We >>> > > > >> > >>> currently do this via the REST API. How are you planning >>> on >>> > > handling >>> > > > >> > >>> these issues in your installer? It would be nice if the >>> > > installer >>> > > > >> was >>> > > > >> > >>> aware of the Keycloak version and could apply "fix-ups" as >>> > > needed >>> > > > >> based >>> > > > >> > >>> on the version. >>> > > > >> > >>> >>> > > > >> > >> >>> > > > >> > >> AFAIK you have one problem? About not all redirect URI >>> included >>> > > from >>> > > > >> the >>> > > > >> > >> SAML entity descriptor. Is that what you are referring to >>> or do >>> > > you >>> > > > >> have >>> > > > >> > >> other problems? >>> > > > >> > >> >>> > > > >> > >> In either case fix-ups should be performed by the client >>> > > registration >>> > > > >> > >> services, not in the CLI. >>> > > > >> > >> >>> > > > >> > >> >>> > > > >> > >>> >>> > > > >> > >>> * Keycloak has two ways to register a client (client >>> > > registration >>> > > > >> > >>> service vs. REST API). The two methods do not produce the >>> same >>> > > > >> client >>> > > > >> > >>> configuration (I suspect because they do not share common >>> code >>> > > in >>> > > > >> the >>> > > > >> > >>> server). How are you planning on addressing the >>> discrepancies? >>> > > > >> > >>> >>> > > > >> > >> >>> > > > >> > >> The task of the CLI is not to address any discrepancies. >>> It's >>> > > just >>> > > > >> > >> invoking the client reg services. Any discrepancies should >>> be >>> > > > >> handled by >>> > > > >> > >> the client reg services themselves. Have you created >>> JIRA's for >>> > > > >> these or >>> > > > >> > >> can you list them to us? >>> > > > >> > >> >>> > > > >> > >> >>> > > > >> > >>> >>> > > > >> > >>> * The tool should be smart enough to produce a working >>> client >>> > > > >> without >>> > > > >> > >>> manual intervention (i.e. the need to run admin cli >>> commands >>> > > > >> afterwards >>> > > > >> > >>> to fix problems). Most admins won't know how to tweak the >>> > > > >> configuration. >>> > > > >> > >>> >>> > > > >> > >> >>> > > > >> > >> Can you list any you are aware of? Same comment as above >>> applies >>> > > > >> though, >>> > > > >> > >> it's the responsibility of the client reg services to >>> handle >>> > > this, >>> > > > >> not the >>> > > > >> > >> CLI. Otherwise you'd have different behavior if you invoke >>> > > client reg >>> > > > >> > >> services directly rather than through the CLI. >>> > > > >> > >> >>> > > > >> > >> >>> > > > >> > >>> >>> > > > >> > >>> * The tool should not have significant dependencies. >>> > > > >> > >>> >>> > > > >> > >> >>> > > > >> > >> It'll be a fat-jar and will have a single dependency on >>> the JVM. >>> > > > >> > >> >>> > > > >> > >> >>> > > > >> > >>> >>> > > > >> > >>> Those are the thoughts off the top of my head, as you >>> fill out >>> > > the >>> > > > >> > >>> details I'll continue to review. Recall the plan of >>> record is >>> > > for >>> > > > >> > >>> Keycloak to provide such tools which we will then >>> utilize. The >>> > > > >> > >>> keycloak-httpd-client-install tool is a stop-gap solution >>> until >>> > > such >>> > > > >> > >>> time as "offical" tools become available. >>> > > > >> > >>> >>> > > > >> > >>> >>> > > > >> > >>> >>> > > > >> > >>> -- >>> > > > >> > >>> John >>> > > > >> > >>> _______________________________________________ >>> > > > >> > >>> 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 >>> > > > >> >>> > > > >> >>> > > > >> -- >>> > > > >> >>> > > > >> abstractj >>> > > > >> PGP: 0x84DC9914 >>> > > > >> >>> > > > > >>> > > > > >>> > > >>> > > -- >>> > > >>> > > abstractj >>> > > PGP: 0x84DC9914 >>> > > >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160701/13646359/attachment-0001.html From sthorger at redhat.com Fri Jul 1 03:05:18 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 09:05:18 +0200 Subject: [keycloak-dev] Please help - need text for SAML HttpBasicAuthenticator In-Reply-To: <5775648C.2010908@redhat.com> References: <5775648C.2010908@redhat.com> Message-ID: I propose: Display type: "HTTP Basic Authentication" Help text: "Validates username and password from Authorization HTTP header" On 30 June 2016 at 20:27, Stan Silvert wrote: > Working on https://issues.jboss.org/browse/RHSSO-274 > > The problem is just that getDisplayType() and getHelpText() return null. > > What text should these two methods return? > > > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/saml/profile/ecp/authenticator/HttpBasicAuthenticator.java > _______________________________________________ > 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/20160701/8c611473/attachment.html From sthorger at redhat.com Fri Jul 1 03:37:00 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 09:37:00 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <577524F4.9070803@redhat.com> References: <577524F4.9070803@redhat.com> Message-ID: I don't like option (a) as it would be very clear what scopes are available and what they result in. You'd have to search through all roles and protocol mappers to find a list of scopes as well as somehow manually build the picture of what a scope implies. A scope could affect: * Behavior - for example openid and offline_access. We can hard code those, but what about others and custom ones? * Roles - limit what roles are included. This is probably the simplest case as it's just about removing roles. * Claims - limit what claims are included in the token. This boils down to protocol mappers. Some protocol mappers would want to be included/excluded based on scope, but I can also see that some protocol mappers would internally look at scope to determine what to include. * Authorization - could also affect authorization separately? The token contains the scope param separately, so authorization policies could be written directly on scope rather than roles/attributes Another thing is that the consent screen (and also showing application access in account management console) should probably take about scope rather than individual roles. For example: * Gallery wants to view your personal details * Backup application wants to access your photos A few more points: * It should be possible to view scopes available for a realm directly, not by scanning through roles and protocol mappers * It should be possible to set a description on a scope * It should be possible to define a scope that maps to multiple roles * It should be possible to define a scope that maps to multiple protocol mappers roles * It may be useful to be able to have protocol mappers that behave differently depending on the scope. Complexity may outweigh usefulness here though. With that in mind I don't think option (a) is great. Option (b) would need introducing a whole new concept. How about we use a combination of (a) and (b), by using composite roles? Something along the lines of: * scope maps to a role. but the role could be a composite role and hence expand to other roles. * Protocol mappers could require a specific role to be applied * We could add a page to view scopes for a realm - This would show the corresponding role as well as effective roles if it's a composite role - It would also list the protocol mappers included One more thing is that maybe when a composite role is used on the consent screen we could have an option if the composite role description should be shown rather than the individual roles? On 30 June 2016 at 15:56, Marek Posolda wrote: > It seems that for OIDC certification, we will need more proper support > for "scope" parameter. There are few tests from OIDC conformance > testsuite, which end with WARNING because of issues with "scope" parameter. > > > SUMMARY OF SPECS REQUIREMENTS > ----------------------------- > > - In OIDC specification, the "scope" parameter is actually REQUIRED. And > you must add the scope value "openid" to all authorization requests. > Hence if you don't use "scope=openid", the request is pure OAuth2 > request, but it's not OIDC request. > > In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the > possibility that we should change our adapters and add "scope=openid" to > all requests, and also the possibility to remove IDToken if it's not > OIDC request (and maybe other things). However it may be potential issue > with backward compatibility with older adapters (which don't add > "scope=openid" at all). > > > - OIDC also prescribes the "scope=offline_access", which you use if you > want offline token. We actually support this as we have realm role > "offline_access", with scopeParamRequired=true . So this role is applied > just if it's included in scope parameter. This is our only support of > scope param actually. ATM we reference the realm roles by name (role > name must match the value of scope parameter) and clientRoles by > "clientId/roleName" . So it's not very flexible and won't work well in > the future with role namespaces. > > > - OIDC defines four other scope values, which we don't support, with the > meaning like this: > > profile > OPTIONAL. This scope value requests access to the End-User's > default profile Claims, which are: "name", "family_name", "given_name", > "middle_name", "nickname", "preferred_username", "profile", "picture", > "website", "gender", "birthdate", "zoneinfo", "locale", and "updated_at". > > email > OPTIONAL. This scope value requests access to the "email" and > "email_verified" Claims. > > address > OPTIONAL. This scope value requests access to the "address" Claim. > > phone > OPTIONAL. This scope value requests access to the "phone_number" > and "phone_number_verified" Claims. > > > - Not directly related to scopes, however OIDC also has one parameter > "claims" described in section > http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter . > This allows to define some additional claims, which should be included > in IDToken or UserInfo endpoint in addition to claims specified by > "scope" parameter. > > > > HOW TO IMPLEMENT? > ----------------- > > My current thinking is, that we will have 2 kinds of protocolMappers and > roles. > > 1) "Always applied" - Those roles/protocolMappers are always applied to > token even if they are not specified by scope parameter. > > 2) "Applied on demand" - Those roles/protocolMappers are applied just if > they are specifically requested by scope parameter > > For roles, we already have that with "scope param required" flag defined > per roleModel. However for protocolMappers we don't have it yet. > > IMO We will also need some more flexible way to specify how the value of > scope parameter will be mapped to roles and protocolMappers. For example > if I use "scope=foo", it can mean that I want realm role "foo1", client > role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc. > > I can see 2 possibilities: > > a) Configure allowed scope param separately per each role / protocolMapper > > If some role has "Scope param required" checked, you will have > possibility to configure list of available values of scope parameter, > which this role will be applied to. This will be configured per-each > role separately. > > Example: I have realm role "foo" . I check "scope param required" to > true. Then I will define "scope param values" : "bar" and "baz". It > means that if someone uses parameter "scope=bar" or > scope=baz", then role "foo" will be applied to token. Otherwise it won't > be applied. > > Similarly it will be for protocolMappers. We will add switch "Scope > param required" to protocolMappers and we will use list of available > values of scope parameter, which is configured per each protocolMapper > separately. > > > b) Configure scope parameter in separate place > > We will have another tab "Scope parameter config" (or maybe rather > another sub-tab under existing "Scope" tab). Here you will define the > allowed values of scope parameter. For each allowed value, you will > define protocolMappers and roles to apply. Hence for example for > "profile" scope parameter, you will define all protocolMappers for > corresponding claims ( name, family_name, ...) here. > > We will still need "scope param required" switch for protocolMappers in > case (b). > > My current thinking is to go with (a). So when you go to some role (or > protocolMapper) in admin console you will see if you need scope > parameter and what are available values of scope parameter to request it. > > WDYT? Another ideas? > > > Marek > > _______________________________________________ > 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/20160701/805be905/attachment.html From sthorger at redhat.com Fri Jul 1 06:39:49 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 12:39:49 +0200 Subject: [keycloak-dev] Is including adapter libs directly in WAR supported on WildFly/EAP Message-ID: Do we support (or need to support) including adapter libraries directly in the WAR? Or should we just support using the subsystem? If we support including libraries directly that may not work at the moment and would certainly require documenting and also testing, so my vote is to only support the subsystem approach. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160701/fec4e4d0/attachment.html From mposolda at redhat.com Fri Jul 1 08:29:07 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 1 Jul 2016 14:29:07 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <1831089249.5182643.1467315726423.JavaMail.zimbra@redhat.com> References: <577524F4.9070803@redhat.com> <1831089249.5182643.1467315726423.JavaMail.zimbra@redhat.com> Message-ID: <57766213.9090803@redhat.com> On 30/06/16 21:42, Pedro Igor Silva wrote: > ----- Original Message ----- >> From: "Marek Posolda" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, June 30, 2016 10:56:04 AM >> Subject: [keycloak-dev] Scope parameter support >> >> IMO We will also need some more flexible way to specify how the value of >> scope parameter will be mapped to roles and protocolMappers. For example >> if I use "scope=foo", it can mean that I want realm role "foo1", client >> role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc. > +1. I think I have mentioned something like that on a previous thread, where we should be able to build scopes from attributes (eg.: from user) or even compose a scope based on multiple attributes. The same concept applies to protocol mappers, just like you proposed. > >> I can see 2 possibilities: >> >> a) Configure allowed scope param separately per each role / protocolMapper >> >> If some role has "Scope param required" checked, you will have >> possibility to configure list of available values of scope parameter, >> which this role will be applied to. This will be configured per-each >> role separately. >> >> Example: I have realm role "foo" . I check "scope param required" to >> true. Then I will define "scope param values" : "bar" and "baz". It >> means that if someone uses parameter "scope=bar" or >> scope=baz", then role "foo" will be applied to token. Otherwise it won't >> be applied. >> >> Similarly it will be for protocolMappers. We will add switch "Scope >> param required" to protocolMappers and we will use list of available >> values of scope parameter, which is configured per each protocolMapper >> separately. > IMO, roles and scopes are separated concepts. Where scopes may also implicate access to the roles granted to an user. Scopes have a pretty broad meaning. > > With that in mind, don't you think that we could just have a scope "roles" ? Which could be used to ask for the roles associated with the user that the client is acting on behalf of ? IMO it will be good that scope can be used to limit/extend the both protocolMappers and roles. For example we use "scope=offline_access" for offline tokens, so the role is applied just if it's included in scope parameter. Then user may also need to grant this role access on consent screen. So just scope "roles" may not be sufficient for fine-grained chose of roles IMO. Marek > > I think that the Protocol Mappers (for OIDC) provide pretty much everything you need. The missing part would be to make it capable of grouping other mappers. Actually, the concept behind a protocol mapper is pretty much > related with a scope. From mposolda at redhat.com Fri Jul 1 08:34:36 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 1 Jul 2016 14:34:36 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: References: <577524F4.9070803@redhat.com> Message-ID: <5776635C.1000606@redhat.com> On 01/07/16 09:37, Stian Thorgersen wrote: > I don't like option (a) as it would be very clear what scopes are > available and what they result in. You'd have to search through all > roles and protocol mappers to find a list of scopes as well as somehow > manually build the picture of what a scope implies. > > A scope could affect: > > * Behavior - for example openid and offline_access. We can hard code > those, but what about others and custom ones? For "openid", I think we can hardcode. I was thinking about adding SPI like ScopeParamMapper or something and drive the behaviour with it, however it won't work well and will require callbacks in various stages (ie. IDToken itself is created at some point, but whole AccessTokenResponse itself and control which tokens go to it is different point. For offline_access we already has that driven by realm role actually. > * Roles - limit what roles are included. This is probably the simplest > case as it's just about removing roles. Not sure what exactly you mean. For roles, we already have the "scopeParamRequired" flag, so we can both include and remove. For example user is member of roleA, roleB, roleC and they have: role-a : scopeParamRequired=false role-b : scopeParamRequired=true role-c : scopeParamRequired=true and request will have "scope=role-b" then in token will be included both role-a and role-b . Just role-c won't be (as it requires scopeParamRequired but wasn't included in scopeParam). We currently use it for offline_access role, which is default role, but have scopeParamRequired, so it's included just if "scope=offline_acces" is used. > * Claims - limit what claims are included in the token. This boils > down to protocol mappers. Some protocol mappers would want to be > included/excluded based on scope, but I can also see that some > protocol mappers would internally look at scope to determine what to > include. > * Authorization - could also affect authorization separately? The > token contains the scope param separately, so authorization policies > could be written directly on scope rather than roles/attributes > > Another thing is that the consent screen (and also showing application > access in account management console) should probably take about scope > rather than individual roles. For example: > > * Gallery wants to view your personal details > * Backup application wants to access your photos > > A few more points: > > * It should be possible to view scopes available for a realm directly, > not by scanning through roles and protocol mappers > * It should be possible to set a description on a scope > * It should be possible to define a scope that maps to multiple roles > * It should be possible to define a scope that maps to multiple > protocol mappers roles > * It may be useful to be able to have protocol mappers that behave > differently depending on the scope. Complexity may outweigh usefulness > here though. > > With that in mind I don't think option (a) is great. Option (b) would > need introducing a whole new concept. > > How about we use a combination of (a) and (b), by using composite > roles? Something along the lines of: > > * scope maps to a role. but the role could be a composite role and > hence expand to other roles. > * Protocol mappers could require a specific role to be applied > * We could add a page to view scopes for a realm > - This would show the corresponding role as well as effective roles > if it's a composite role > - It would also list the protocol mappers included +1 to this concept and "mapping" scope param values to roles. However there are some things to clarify. - OIDC specs has definition for scopes like "phone" , "email" and "profile" . So we will need the roles for those. Isn't that confusing a bit? IMO our RoleModel applies well for the scope parameter, just not sure if it's not rather mis-using of role concept and bit confusing for users? - My understanding is, that scope is per-client thing rather than per-realm thing? For example if you use "scope=photo", it's applicable just for client "photogallery". Also the same scope parameter may have different meaning for different clients ( eg. if you use "scope=admin" in client "product-app" , the token will receive claims/permissions for managing products. However using "scope=admin" in client "customer-app" , the token will manage customers). So with respect to this, scope looks to me more like either per-client thing or per-clientTemplate thing (if some logic is common for more clients). - We will need some way how to map value of scope parameter to particular role. The simple (but probably not correct) way: On role definition, we can have something like "Scope param value" where you can configure value "photo" and it would mean that the "scope=photo" is related to this paricular role. However what if there are clashes? For example someone can configure the scope parameter value "photo" for realm role "realm-photo-role" or client role "photogalery/client-photo-role" . Then when you use "scope=photo", which one will be used? So after we add roleNamespaces, I can imagine something like this: - Each client will have reserved namespace, where all roles mapped to "scope" parameter lives. Also each clientTemplate will have such namespace. - After creation of client, there will be a set of corresponding roles added automatically for the client like: "prefix:/clients/my-client-id/scope-param/phone" "prefix:/clients/my-client-id/scope-param/address" "prefix:/clients/my-client-id/scope-param/profile" "prefix:/clients/my-client-id/scope-param/offline_access" You won't need to configure "Scope param name" as that will be based on the roleName - Those roles won't be default roles and won't be automatically assigned to users. However any user, who uses "scope=phone" can request the scope "phone" with corresponding protocolMappers and children composite roles. - If role is assigned to user directly, it will be always used even if it's not used in scope parameter. So user assigned to role "phone" will automatically receive "phone" and "phone_verified" protocolMappers. - Keycloak will browse roles from the "scope-param" namespace of particular client, and then also roles from "scope-param" namespace of clientTemplate. So clientTemplate can have namespace for scope parameters, which can be used if there is some "common" scope applicable to more clients with common set of protocolMappers from this clientTemplate. - For the scopes like "phone" "address" and "profile" it's pretty straightforward. It seems we will need protocolMappers for every OIDC defined claim (address, phone, gender, birthday etc) and those will have role required. So for example protocolMapper for "birthday" will require role "profile" , protocolMapper for "phone" will require role "phone" etc. Basic existing protocolMappers ( name, "preferred_username" etc) . - For the "prefix:/clients/my-client-id/scope-param/offline_access" role, it will have one composite role, which is current realm role "offline_access" . The current "offline_access" realm role is default role with scopeParamRequired=true, so it's applied just if it's requested (directly or indirectly) through scope parameter. If client doesn't need offline tokens and "offline_access" scope, the namespaced role "prefix:/clients/my-client-id/scope-param/offline_access". Also if you remove realm role "offline_access" from user, you disallow him to request offline tokens. It's currently realm role, hence it's global setting (so you can't reject user from offline tokens for "clientA" but allow him request offline tokens in "clientB") . Marek > > One more thing is that maybe when a composite role is used on the > consent screen we could have an option if the composite role > description should be shown rather than the individual roles? > > On 30 June 2016 at 15:56, Marek Posolda > wrote: > > It seems that for OIDC certification, we will need more proper support > for "scope" parameter. There are few tests from OIDC conformance > testsuite, which end with WARNING because of issues with "scope" > parameter. > > > SUMMARY OF SPECS REQUIREMENTS > ----------------------------- > > - In OIDC specification, the "scope" parameter is actually > REQUIRED. And > you must add the scope value "openid" to all authorization requests. > Hence if you don't use "scope=openid", the request is pure OAuth2 > request, but it's not OIDC request. > > In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the > possibility that we should change our adapters and add > "scope=openid" to > all requests, and also the possibility to remove IDToken if it's not > OIDC request (and maybe other things). However it may be potential > issue > with backward compatibility with older adapters (which don't add > "scope=openid" at all). > > > - OIDC also prescribes the "scope=offline_access", which you use > if you > want offline token. We actually support this as we have realm role > "offline_access", with scopeParamRequired=true . So this role is > applied > just if it's included in scope parameter. This is our only support of > scope param actually. ATM we reference the realm roles by name (role > name must match the value of scope parameter) and clientRoles by > "clientId/roleName" . So it's not very flexible and won't work well in > the future with role namespaces. > > > - OIDC defines four other scope values, which we don't support, > with the > meaning like this: > > profile > OPTIONAL. This scope value requests access to the End-User's > default profile Claims, which are: "name", "family_name", > "given_name", > "middle_name", "nickname", "preferred_username", "profile", "picture", > "website", "gender", "birthdate", "zoneinfo", "locale", and > "updated_at". > > email > OPTIONAL. This scope value requests access to the "email" and > "email_verified" Claims. > > address > OPTIONAL. This scope value requests access to the "address" > Claim. > > phone > OPTIONAL. This scope value requests access to the "phone_number" > and "phone_number_verified" Claims. > > > - Not directly related to scopes, however OIDC also has one parameter > "claims" described in section > http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter . > This allows to define some additional claims, which should be included > in IDToken or UserInfo endpoint in addition to claims specified by > "scope" parameter. > > > > HOW TO IMPLEMENT? > ----------------- > > My current thinking is, that we will have 2 kinds of > protocolMappers and > roles. > > 1) "Always applied" - Those roles/protocolMappers are always > applied to > token even if they are not specified by scope parameter. > > 2) "Applied on demand" - Those roles/protocolMappers are applied > just if > they are specifically requested by scope parameter > > For roles, we already have that with "scope param required" flag > defined > per roleModel. However for protocolMappers we don't have it yet. > > IMO We will also need some more flexible way to specify how the > value of > scope parameter will be mapped to roles and protocolMappers. For > example > if I use "scope=foo", it can mean that I want realm role "foo1", > client > role "client1/foo2" and protocolMapper for "firstName" and > "lastName" etc. > > I can see 2 possibilities: > > a) Configure allowed scope param separately per each role / > protocolMapper > > If some role has "Scope param required" checked, you will have > possibility to configure list of available values of scope parameter, > which this role will be applied to. This will be configured per-each > role separately. > > Example: I have realm role "foo" . I check "scope param required" to > true. Then I will define "scope param values" : "bar" and "baz". It > means that if someone uses parameter "scope=bar" or > scope=baz", then role "foo" will be applied to token. Otherwise it > won't > be applied. > > Similarly it will be for protocolMappers. We will add switch "Scope > param required" to protocolMappers and we will use list of available > values of scope parameter, which is configured per each protocolMapper > separately. > > > b) Configure scope parameter in separate place > > We will have another tab "Scope parameter config" (or maybe rather > another sub-tab under existing "Scope" tab). Here you will define the > allowed values of scope parameter. For each allowed value, you will > define protocolMappers and roles to apply. Hence for example for > "profile" scope parameter, you will define all protocolMappers for > corresponding claims ( name, family_name, ...) here. > > We will still need "scope param required" switch for > protocolMappers in > case (b). > > My current thinking is to go with (a). So when you go to some role (or > protocolMapper) in admin console you will see if you need scope > parameter and what are available values of scope parameter to > request it. > > WDYT? Another ideas? > > > Marek > > _______________________________________________ > 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/20160701/48de5b1f/attachment-0001.html From mposolda at redhat.com Fri Jul 1 08:36:03 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 1 Jul 2016 14:36:03 +0200 Subject: [keycloak-dev] Backward compatibility of server and adapters In-Reply-To: References: <57752604.9070103@redhat.com> Message-ID: <577663B3.2000901@redhat.com> +1 Marek On 01/07/16 08:43, Stian Thorgersen wrote: > I'm not convinced about that approach. We'll end up having to test and > maintain this in the long run. > > How about a staged approach instead: > > * Keycloak 2.1 & RH-SSO 7.0.1 - add scope=openid, also add mention in > release not and migration guide that the ID token will soon not be > included anymore > * Keycloak 2.3 & RH-SSO 7.1 - stop sending ID token if scope is not > included > > On 30 June 2016 at 16:00, Marek Posolda > wrote: > > I am thinking whether to add configuration switch in admin console per > client, where you can define what is the adapter version the > particular > client is using. In that case, some behaviour can be > different/backwards > compatible. > > Example: For new clients, we will include IDToken just if they use > "scope=openid" . However for clients with adapter "1.9" or older, the > IDToken will be included even if "scope=openid" is not used. > > WDYT? > Marek > _______________________________________________ > 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/20160701/8957ed71/attachment.html From mposolda at redhat.com Fri Jul 1 08:44:25 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 1 Jul 2016 14:44:25 +0200 Subject: [keycloak-dev] Some OIDC JIRAs to fix? In-Reply-To: References: <57752BBD.2080107@redhat.com> Message-ID: <577665A9.8040601@redhat.com> On 01/07/16 08:58, Stian Thorgersen wrote: > > > On 30 June 2016 at 16:25, Marek Posolda > wrote: > > I am adding some OIDC specs JIRAs with possibility how to fix > them. I am including those, which will be easy to fix and I can > look into them later today or tomorrow before PTO : > > https://issues.jboss.org/browse/KEYCLOAK-3189 - Add 'typ' to JWT > header > > > +1 > > https://issues.jboss.org/browse/KEYCLOAK-3190 > - Add 'kid' to JWT header > > > +1 > > > https://issues.jboss.org/browse/KEYCLOAK-3217 - UserInfo endpoint > not accessible by POST request secured with Bearer header > > > +1 > > https://issues.jboss.org/browse/KEYCLOAK-3147 - OpenID Connect > auth request redirect_uri behaviour not according to spec > > > +1 To just require redirect_uri in either case > > We need separate JIRAs for scope=openid and another one for removal of > ID token when scope=openid isn't used For now, I've created https://issues.jboss.org/browse/KEYCLOAK-3237 for both things. > > https://issues.jboss.org/browse/KEYCLOAK-3222 > - WellKnown endpoint doesn't return supported types of client > authentication > > > +1 > > https://issues.jboss.org/browse/KEYCLOAK-3219 - WellKnown endpoint > doesn't support claims_supported > > > Maybe this one isn't so straightforward due to protocol mappers? Yes, right. Just publish it with some value will be easy (and probably will make OIDC test happy :) ) but tricky part is which value to use... > > > > All of those are quite straightforward and easy to fix IMO. > > > Besides that, there are those 2, which I first rather want to > confirm what exactly to do: > > - https://issues.jboss.org/browse/KEYCLOAK-3221 Tokens not > invalidated if an attempt to reuse code is made > > We have just single-use code (which is good), however OAuth2 specs > recommends to invalidate existing tokens if an attempt to reuse > code is done. And one OIDC test is in WARNING state because of it > (it tries to access UserInfo endpoint with the accessToken issued > with the reused code). > > I can see 2 possibilities to fix: > a) Invalidate just single clientSession where "code" attempt reuse > was made > b) Logout whole userSession > > It looks to me that (a) is sufficient solution. The potential > issue with (b) is, that if attacker can steal code, it gives him > the possibility to trigger global logout of user from all apps. WDYT? > > > I think option (a) is the correct approach. I interpret the spec to > state that tokens associated with the specific code should be > invalidated. Option (b) seems a bit over the top and not necessary I > also wonder if there's non-malicious situations where an application > could try to exchange a code twice, for example after a timeout or an > automated connection retry? Not sure if this can be really an issue... Maybe we can fix and see if someone see issues? Marek > > > > - https://issues.jboss.org/browse/KEYCLOAK-3218 Support for > "max_age" in AuthorizationEndpoint and "auth_time" claim on IDToken > > The possibility to implement is : > - Add new note AUTH_TIME to UserSessionModel. It will be time when > authentication of user was fully finished (including > requiredActions). Session note is used just so we don't need to > change the model ;) > - If "max_age" parameter was requested, the "auth_time" will be > added to IDToken (or I will re-check specs if we should rather > always add it to IDToken) > - I am also thinking about adding hook to CookieAuthenticator, so > that if max_age parameter was used and userSession authTime is too > "old", the CookieAuthenticator will be ignored and user will need > to re-authenticate with other authenticators (username/password > form etc). Then authTime will be updated on userSession once > authentication is finished. > > > +1 Sounds good > > > WDYT? > > That will leave us with bigger things for OIDC Basic certification > ( scope parameter support, possibly 'claims' param support and > 'acr' support). > > Marek > > _______________________________________________ > 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/20160701/2b7931b9/attachment.html From sthorger at redhat.com Fri Jul 1 08:45:29 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 14:45:29 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <5776635C.1000606@redhat.com> References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> Message-ID: On 1 July 2016 at 14:34, Marek Posolda wrote: > On 01/07/16 09:37, Stian Thorgersen wrote: > > I don't like option (a) as it would be very clear what scopes are > available and what they result in. You'd have to search through all roles > and protocol mappers to find a list of scopes as well as somehow manually > build the picture of what a scope implies. > > A scope could affect: > > * Behavior - for example openid and offline_access. We can hard code > those, but what about others and custom ones? > > For "openid", I think we can hardcode. I was thinking about adding SPI > like ScopeParamMapper or something and drive the behaviour with it, however > it won't work well and will require callbacks in various stages (ie. > IDToken itself is created at some point, but whole AccessTokenResponse > itself and control which tokens go to it is different point. > > For offline_access we already has that driven by realm role actually. > > * Roles - limit what roles are included. This is probably the simplest > case as it's just about removing roles. > > Not sure what exactly you mean. For roles, we already have the > "scopeParamRequired" flag, so we can both include and remove. For example > user is member of roleA, roleB, roleC and they have: > role-a : scopeParamRequired=false > role-b : scopeParamRequired=true > role-c : scopeParamRequired=true > > and request will have "scope=role-b" then in token will be included both > role-a and role-b . Just role-c won't be (as it requires scopeParamRequired > but wasn't included in scopeParam). > > We currently use it for offline_access role, which is default role, but > have scopeParamRequired, so it's included just if "scope=offline_acces" is > used. > I meant that a single scope should be able to change several things, not just enable/disable a single role. > > * Claims - limit what claims are included in the token. This boils down to > protocol mappers. Some protocol mappers would want to be included/excluded > based on scope, but I can also see that some protocol mappers would > internally look at scope to determine what to include. > * Authorization - could also affect authorization separately? The token > contains the scope param separately, so authorization policies could be > written directly on scope rather than roles/attributes > > Another thing is that the consent screen (and also showing application > access in account management console) should probably take about scope > rather than individual roles. For example: > > * Gallery wants to view your personal details > * Backup application wants to access your photos > > A few more points: > > * It should be possible to view scopes available for a realm directly, not > by scanning through roles and protocol mappers > * It should be possible to set a description on a scope > * It should be possible to define a scope that maps to multiple roles > * It should be possible to define a scope that maps to multiple protocol > mappers roles > * It may be useful to be able to have protocol mappers that behave > differently depending on the scope. Complexity may outweigh usefulness here > though. > > With that in mind I don't think option (a) is great. Option (b) would need > introducing a whole new concept. > > How about we use a combination of (a) and (b), by using composite roles? > Something along the lines of: > > * scope maps to a role. but the role could be a composite role and hence > expand to other roles. > * Protocol mappers could require a specific role to be applied > * We could add a page to view scopes for a realm > - This would show the corresponding role as well as effective roles if > it's a composite role > - It would also list the protocol mappers included > > +1 to this concept and "mapping" scope param values to roles. However > there are some things to clarify. > > - OIDC specs has definition for scopes like "phone" , "email" and > "profile" . So we will need the roles for those. Isn't that confusing a > bit? IMO our RoleModel applies well for the scope parameter, just not sure > if it's not rather mis-using of role concept and bit confusing for users? > Would be better if we had role namespaces as we could then have a OIDC namespace. That would remove some of the confusion I think. > > - My understanding is, that scope is per-client thing rather than > per-realm thing? For example if you use "scope=photo", it's applicable just > for client "photogallery". Also the same scope parameter may have different > meaning for different clients ( eg. if you use "scope=admin" in client > "product-app" , the token will receive claims/permissions for managing > products. However using "scope=admin" in client "customer-app" , the token > will manage customers). So with respect to this, scope looks to me more > like either per-client thing or per-clientTemplate thing (if some logic is > common for more clients). > Not sure I full agree with that. I think it can be a per-realm and per-client thing, at least per group of clients. The scope could affect the app, services it invokes and also authorization policies. I would actually think that most organizations would define a "organization" level scopes rather than per-client scopes. > > - We will need some way how to map value of scope parameter to particular > role. > The simple (but probably not correct) way: On role definition, we can have > something like "Scope param value" where you can configure value "photo" > and it would mean that the "scope=photo" is related to this paricular role. > However what if there are clashes? For example someone can configure the > scope parameter value "photo" for realm role "realm-photo-role" or client > role "photogalery/client-photo-role" . Then when you use "scope=photo", > which one will be used? > > Why not just use the role name as the scope name? A composite role can be used to create an "alias" if required. > So after we add roleNamespaces, I can imagine something like this: > - Each client will have reserved namespace, where all roles mapped to > "scope" parameter lives. Also each clientTemplate will have such namespace. > > - After creation of client, there will be a set of corresponding roles > added automatically for the client like: > "prefix:/clients/my-client-id/scope-param/phone" > "prefix:/clients/my-client-id/scope-param/address" > "prefix:/clients/my-client-id/scope-param/profile" > "prefix:/clients/my-client-id/scope-param/offline_access" > > You won't need to configure "Scope param name" as that will be based on > the roleName > > - Those roles won't be default roles and won't be automatically assigned > to users. However any user, who uses "scope=phone" can request the scope > "phone" with corresponding protocolMappers and children composite roles. > > - If role is assigned to user directly, it will be always used even if > it's not used in scope parameter. So user assigned to role "phone" will > automatically receive "phone" and "phone_verified" protocolMappers. > > - Keycloak will browse roles from the "scope-param" namespace of > particular client, and then also roles from "scope-param" namespace of > clientTemplate. So clientTemplate can have namespace for scope parameters, > which can be used if there is some "common" scope applicable to more > clients with common set of protocolMappers from this clientTemplate. > > - For the scopes like "phone" "address" and "profile" it's pretty > straightforward. It seems we will need protocolMappers for every OIDC > defined claim (address, phone, gender, birthday etc) and those will have > role required. So for example protocolMapper for "birthday" will require > role "profile" , protocolMapper for "phone" will require role "phone" etc. > Basic existing protocolMappers ( name, "preferred_username" etc) . > > - For the "prefix:/clients/my-client-id/scope-param/offline_access" role, > it will have one composite role, which is current realm role > "offline_access" . The current "offline_access" realm role is default role > with scopeParamRequired=true, so it's applied just if it's requested > (directly or indirectly) through scope parameter. If client doesn't need > offline tokens and "offline_access" scope, the namespaced role > "prefix:/clients/my-client-id/scope-param/offline_access". Also if you > remove realm role "offline_access" from user, you disallow him to request > offline tokens. It's currently realm role, hence it's global setting (so > you can't reject user from offline tokens for "clientA" but allow him > request offline tokens in "clientB") . > Reading all of this makes me think it would be cleaner to introduce a separate scope concept ;) A user doesn't have a scope - a user has roles and attributes. Re-using roles concept for the scope just makes it feel awkward and retrofitted. > > > Marek > > > > One more thing is that maybe when a composite role is used on the consent > screen we could have an option if the composite role description should be > shown rather than the individual roles? > > On 30 June 2016 at 15:56, Marek Posolda wrote: > >> It seems that for OIDC certification, we will need more proper support >> for "scope" parameter. There are few tests from OIDC conformance >> testsuite, which end with WARNING because of issues with "scope" >> parameter. >> >> >> SUMMARY OF SPECS REQUIREMENTS >> ----------------------------- >> >> - In OIDC specification, the "scope" parameter is actually REQUIRED. And >> you must add the scope value "openid" to all authorization requests. >> Hence if you don't use "scope=openid", the request is pure OAuth2 >> request, but it's not OIDC request. >> >> In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the >> possibility that we should change our adapters and add "scope=openid" to >> all requests, and also the possibility to remove IDToken if it's not >> OIDC request (and maybe other things). However it may be potential issue >> with backward compatibility with older adapters (which don't add >> "scope=openid" at all). >> >> >> - OIDC also prescribes the "scope=offline_access", which you use if you >> want offline token. We actually support this as we have realm role >> "offline_access", with scopeParamRequired=true . So this role is applied >> just if it's included in scope parameter. This is our only support of >> scope param actually. ATM we reference the realm roles by name (role >> name must match the value of scope parameter) and clientRoles by >> "clientId/roleName" . So it's not very flexible and won't work well in >> the future with role namespaces. >> >> >> - OIDC defines four other scope values, which we don't support, with the >> meaning like this: >> >> profile >> OPTIONAL. This scope value requests access to the End-User's >> default profile Claims, which are: "name", "family_name", "given_name", >> "middle_name", "nickname", "preferred_username", "profile", "picture", >> "website", "gender", "birthdate", "zoneinfo", "locale", and "updated_at". >> >> email >> OPTIONAL. This scope value requests access to the "email" and >> "email_verified" Claims. >> >> address >> OPTIONAL. This scope value requests access to the "address" Claim. >> >> phone >> OPTIONAL. This scope value requests access to the "phone_number" >> and "phone_number_verified" Claims. >> >> >> - Not directly related to scopes, however OIDC also has one parameter >> "claims" described in section >> http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter . >> This allows to define some additional claims, which should be included >> in IDToken or UserInfo endpoint in addition to claims specified by >> "scope" parameter. >> >> >> >> HOW TO IMPLEMENT? >> ----------------- >> >> My current thinking is, that we will have 2 kinds of protocolMappers and >> roles. >> >> 1) "Always applied" - Those roles/protocolMappers are always applied to >> token even if they are not specified by scope parameter. >> >> 2) "Applied on demand" - Those roles/protocolMappers are applied just if >> they are specifically requested by scope parameter >> >> For roles, we already have that with "scope param required" flag defined >> per roleModel. However for protocolMappers we don't have it yet. >> >> IMO We will also need some more flexible way to specify how the value of >> scope parameter will be mapped to roles and protocolMappers. For example >> if I use "scope=foo", it can mean that I want realm role "foo1", client >> role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc. >> >> I can see 2 possibilities: >> >> a) Configure allowed scope param separately per each role / protocolMapper >> >> If some role has "Scope param required" checked, you will have >> possibility to configure list of available values of scope parameter, >> which this role will be applied to. This will be configured per-each >> role separately. >> >> Example: I have realm role "foo" . I check "scope param required" to >> true. Then I will define "scope param values" : "bar" and "baz". It >> means that if someone uses parameter "scope=bar" or >> scope=baz", then role "foo" will be applied to token. Otherwise it won't >> be applied. >> >> Similarly it will be for protocolMappers. We will add switch "Scope >> param required" to protocolMappers and we will use list of available >> values of scope parameter, which is configured per each protocolMapper >> separately. >> >> >> b) Configure scope parameter in separate place >> >> We will have another tab "Scope parameter config" (or maybe rather >> another sub-tab under existing "Scope" tab). Here you will define the >> allowed values of scope parameter. For each allowed value, you will >> define protocolMappers and roles to apply. Hence for example for >> "profile" scope parameter, you will define all protocolMappers for >> corresponding claims ( name, family_name, ...) here. >> >> We will still need "scope param required" switch for protocolMappers in >> case (b). >> >> My current thinking is to go with (a). So when you go to some role (or >> protocolMapper) in admin console you will see if you need scope >> parameter and what are available values of scope parameter to request it. >> >> WDYT? Another ideas? >> >> >> Marek >> >> _______________________________________________ >> 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/20160701/092c4d5c/attachment-0001.html From sthorger at redhat.com Fri Jul 1 08:46:17 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 14:46:17 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <57766213.9090803@redhat.com> References: <577524F4.9070803@redhat.com> <1831089249.5182643.1467315726423.JavaMail.zimbra@redhat.com> <57766213.9090803@redhat.com> Message-ID: I'm definitively leaning towards introducing a new concept called scopes, rather than trying to shoehorn this into roles. On 1 July 2016 at 14:29, Marek Posolda wrote: > On 30/06/16 21:42, Pedro Igor Silva wrote: > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, June 30, 2016 10:56:04 AM > >> Subject: [keycloak-dev] Scope parameter support > >> > >> IMO We will also need some more flexible way to specify how the value of > >> scope parameter will be mapped to roles and protocolMappers. For example > >> if I use "scope=foo", it can mean that I want realm role "foo1", client > >> role "client1/foo2" and protocolMapper for "firstName" and "lastName" > etc. > > +1. I think I have mentioned something like that on a previous thread, > where we should be able to build scopes from attributes (eg.: from user) or > even compose a scope based on multiple attributes. The same concept applies > to protocol mappers, just like you proposed. > > > >> I can see 2 possibilities: > >> > >> a) Configure allowed scope param separately per each role / > protocolMapper > >> > >> If some role has "Scope param required" checked, you will have > >> possibility to configure list of available values of scope parameter, > >> which this role will be applied to. This will be configured per-each > >> role separately. > >> > >> Example: I have realm role "foo" . I check "scope param required" to > >> true. Then I will define "scope param values" : "bar" and "baz". It > >> means that if someone uses parameter "scope=bar" or > >> scope=baz", then role "foo" will be applied to token. Otherwise it won't > >> be applied. > >> > >> Similarly it will be for protocolMappers. We will add switch "Scope > >> param required" to protocolMappers and we will use list of available > >> values of scope parameter, which is configured per each protocolMapper > >> separately. > > IMO, roles and scopes are separated concepts. Where scopes may also > implicate access to the roles granted to an user. Scopes have a pretty > broad meaning. > > > > With that in mind, don't you think that we could just have a scope > "roles" ? Which could be used to ask for the roles associated with the user > that the client is acting on behalf of ? > IMO it will be good that scope can be used to limit/extend the both > protocolMappers and roles. For example we use "scope=offline_access" for > offline tokens, so the role is applied just if it's included in scope > parameter. Then user may also need to grant this role access on consent > screen. > > So just scope "roles" may not be sufficient for fine-grained chose of > roles IMO. > > Marek > > > > I think that the Protocol Mappers (for OIDC) provide pretty much > everything you need. The missing part would be to make it capable of > grouping other mappers. Actually, the concept behind a protocol mapper is > pretty much > > related with a scope. > > _______________________________________________ > 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/20160701/539efd48/attachment.html From sthorger at redhat.com Fri Jul 1 08:49:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 14:49:22 +0200 Subject: [keycloak-dev] Some OIDC JIRAs to fix? In-Reply-To: <577665A9.8040601@redhat.com> References: <57752BBD.2080107@redhat.com> <577665A9.8040601@redhat.com> Message-ID: On 1 July 2016 at 14:44, Marek Posolda wrote: > On 01/07/16 08:58, Stian Thorgersen wrote: > > > > On 30 June 2016 at 16:25, Marek Posolda wrote: > >> I am adding some OIDC specs JIRAs with possibility how to fix them. I am >> including those, which will be easy to fix and I can look into them later >> today or tomorrow before PTO : >> >> https://issues.jboss.org/browse/KEYCLOAK-3189 - Add 'typ' to JWT header >> > > +1 > > >> >> https://issues.jboss.org/browse/KEYCLOAK-3190 >> - Add 'kid' to JWT header >> > > +1 > > >> >> https://issues.jboss.org/browse/KEYCLOAK-3217 - UserInfo endpoint not >> accessible by POST request secured with Bearer header >> > > +1 > > >> >> https://issues.jboss.org/browse/KEYCLOAK-3147 - OpenID Connect auth >> request redirect_uri behaviour not according to spec >> > > +1 To just require redirect_uri in either case > > We need separate JIRAs for scope=openid and another one for removal of ID > token when scope=openid isn't used > > For now, I've created https://issues.jboss.org/browse/KEYCLOAK-3237 for > both things. > > > >> >> https://issues.jboss.org/browse/KEYCLOAK-3222 >> - WellKnown endpoint doesn't return supported types of client >> authentication >> > > +1 > > >> https://issues.jboss.org/browse/KEYCLOAK-3219 >> - WellKnown endpoint doesn't support claims_supported >> > > Maybe this one isn't so straightforward due to protocol mappers? > > Yes, right. Just publish it with some value will be easy (and probably > will make OIDC test happy :) ) but tricky part is which value to use... > > > >> >> >> All of those are quite straightforward and easy to fix IMO. >> >> >> Besides that, there are those 2, which I first rather want to confirm >> what exactly to do: >> >> - https://issues.jboss.org/browse/KEYCLOAK-3221 Tokens not invalidated >> if an attempt to reuse code is made >> >> We have just single-use code (which is good), however OAuth2 specs >> recommends to invalidate existing tokens if an attempt to reuse code is >> done. And one OIDC test is in WARNING state because of it (it tries to >> access UserInfo endpoint with the accessToken issued with the reused code). >> >> I can see 2 possibilities to fix: >> a) Invalidate just single clientSession where "code" attempt reuse was >> made >> b) Logout whole userSession >> >> It looks to me that (a) is sufficient solution. The potential issue with >> (b) is, that if attacker can steal code, it gives him the possibility to >> trigger global logout of user from all apps. WDYT? >> > > I think option (a) is the correct approach. I interpret the spec to state > that tokens associated with the specific code should be invalidated. Option > (b) seems a bit over the top and not necessary I also wonder if there's > non-malicious situations where an application could try to exchange a code > twice, for example after a timeout or an automated connection retry? > > Not sure if this can be really an issue... Maybe we can fix and see if > someone see issues? > It's not an option if we go with (a), but it's a potential issue if we go with (b). We may not even know the correct user session if the client session doesn't exist. My vote is let's stick with option (a). > > > Marek > > > >> >> >> - https://issues.jboss.org/browse/KEYCLOAK-3218 Support for "max_age" in >> AuthorizationEndpoint and "auth_time" claim on IDToken >> >> The possibility to implement is : >> - Add new note AUTH_TIME to UserSessionModel. It will be time when >> authentication of user was fully finished (including requiredActions). >> Session note is used just so we don't need to change the model ;) >> - If "max_age" parameter was requested, the "auth_time" will be added to >> IDToken (or I will re-check specs if we should rather always add it to >> IDToken) >> - I am also thinking about adding hook to CookieAuthenticator, so that if >> max_age parameter was used and userSession authTime is too "old", the >> CookieAuthenticator will be ignored and user will need to re-authenticate >> with other authenticators (username/password form etc). Then authTime will >> be updated on userSession once authentication is finished. >> > > +1 Sounds good > > >> >> WDYT? >> >> That will leave us with bigger things for OIDC Basic certification ( >> scope parameter support, possibly 'claims' param support and 'acr' support). >> >> Marek >> >> _______________________________________________ >> 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/20160701/3b6c27c8/attachment-0001.html From psilva at redhat.com Fri Jul 1 08:57:22 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 1 Jul 2016 08:57:22 -0400 (EDT) Subject: [keycloak-dev] Scope parameter support In-Reply-To: References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> Message-ID: <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> > Reading all of this makes me think it would be cleaner to introduce a > separate scope concept ;) > > A user doesn't have a scope - a user has roles and attributes. Re-using roles > concept for the scope just makes it feel awkward and retrofitted. +10000 From sthorger at redhat.com Fri Jul 1 09:14:41 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jul 2016 15:14:41 +0200 Subject: [keycloak-dev] Want to work on Keycloak? Message-ID: We're looking for two people to join our team so if anyone is interested you can contact me directly or apply online. For more details about the positions take a look at the job descriptions: * SDK and developer experience - https://careers-redhat.icims.com/jobs/53428/senior-software-engineer/job * Web Application developer - https://careers-redhat.icims.com/jobs/51802/senior-software-engineer/job -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160701/fe5251ac/attachment.html From mposolda at redhat.com Fri Jul 1 15:45:27 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 1 Jul 2016 21:45:27 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> Message-ID: <5776C857.2070703@redhat.com> Ok, I wasn't also 100% keen about using role. Thinking also about what Pedro mentioned before about protocol mappers. So I wonder that instead of introduce new "scope" concept, we just reuse protocolMappers SPI and have special impl of protocolMapper, which is able to deal with scope parameter and aggregate other "children" protocolMappers and roles? Something like this: - There will be new ProtocolMapper implementation like ScopeAggregatorProtocolMapper. You will define value of scope parameter (eg. "photo" ) in the configuration of this protocolMapper. Mapper will be ignored if scope parameter value with this name was not used. - You will be able to define "children" protocolMappers and "children" roles in ScopeAggregatorProtocolMapper. - For each client (and clientTemplate), we will have many defined protocolMappers, but just some subset of them are "root" mappers, which are applied by default. The rest of mappers will be used just as "children" of root mappers. So in client model, we might have: client.getDefinedProtocolMappers() // all defined client.getProtocolMappers() // just subset of defined (defacto root mappers) - For example: client will have defined protocolMappers: firstName, lastName, birthday, profile, email. Just "profile" and "email" will be root mappers. And "profile" is ScopeAggregatorMapper for scope value "profile" and it's children mappers are : firstName, lastName, birthday. So then: -- user will send "scope=profile" . Then defacto all of "firstName", "lastName", "birthday", "email" claims will be included in token. On consent screen will be just "Profile" and "Email" -- user won't send "scope=profile" . Then defacto just "email" claim will be included (So for this example, email is always included even if not specified by scope parameter). - With this concept, we are able to aggregate many various claims into single value of "scope" and on the consent screen have just the roots. This would fit well for the default scope values mentioned by OIDC specs. We are also able to define mappers (claims), which will be always available even if not specified by scope parameter. - For the roles, I am not 100% sure whether to include them into the concept or not? However it seems to me that rather yes. The particular role will be applied into token just if all of those 3 conditions are met: 1) user is member of the role 2) client has scope for the role (so current "scope" tab in clients will remain as is) 3) if role has scopePAramRequired=true, then it must be included in some mapper (in other words, those roles are not included directly in clientSession.getRoles , but it's the responsibility of ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are met). So again, user won't see all children roles on consent screen. Just the parent protocolMapper. This will work fine with "scope=offline_access" . There will be protocolMapper for "offline_access" parameter, which will aggregate just one children role (the current realm role "offline_access"). The offline token will be issued just if accessToken will have "offline_access" permission. So if some client, doesn't need offline tokens, it can just remove "offline_access" protocolMapper. Also if some user shouldn't be allowed to request offline tokens, admin can remove him from the "offline_access" role. - If some scope parameter is applicable for more clients, it can be defined on clientTemplate. PS: I will be on holidays and back on next Thursday 7th July. So sorry if I won't reply immediately to next mails. Mare On 01/07/16 14:57, Pedro Igor Silva wrote: >> Reading all of this makes me think it would be cleaner to introduce a >> separate scope concept ;) >> >> A user doesn't have a scope - a user has roles and attributes. Re-using roles >> concept for the scope just makes it feel awkward and retrofitted. > +10000 From singhrasster at gmail.com Sat Jul 2 20:13:01 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Sat, 2 Jul 2016 19:13:01 -0500 Subject: [keycloak-dev] How to setup a maven project generating jar containing authentication providers in a debug mode in eclipse In-Reply-To: References: Message-ID: Thanks for your reply Francis. I still have one problem: When I run this: $ docker run --name keycloak1 -p 8080:8080 -p 8787:8787 jboss/keycloak I can access the keycloak app console on http://192.168.99.100:8080/auth/ from my browser But when I run it in debug mode as: $ docker run --name keycloak1 -p 8080:8080 -p 8787:8787 jboss/keycloak --debug I cannot access the keycloak console. What is wrong here, any idea? On Fri, Jul 1, 2016 at 12:48 AM, Francis Pouatcha < francis.pouatcha at adorsys.com> wrote: > Rashmi, > > follow these instructions to have keycloack debug accessible from eclipse: > > 1- Simple web application > User a simple HelloServlet to try out the debugging process before > applying you experience to wildfly. > > 1- Wildfly and eclipse > Like Thomas mentioned, Make sure you active the debug property while > starting wildfly. This is independent of keycloak, as keycloak is just > another web application running on wildfly. So make sure you have a simple > webapp running in wildfly standalone so you can get used to the debugging > process. > > 2- Wildfly in a docker container > Take your simple web application and wildfly into a docker container and > try following: > a) Make sure you start wildfly in the container in debug mode. Not matter > how you manage the docker containers in your development environment, you > will have to expose their ports so you can reach the container from and > outside the docker host. "Exposing the port means mapping the defined > wildfly ports to some other ports on the docker host. If you are using > docker-composer you have to try something like: ports:\ - "8080:8080"\ > - "8787:8787". In this case see the docker-compose reference for details. > > 3- Accessing the docker container > Once you wildfly docker container is startet in debug mode, make sure you > can access you HelloServlet from a web browser on the same machine on > which you have your eclipse installed. If this works, use the same hostname > or ip to replace "localhost" in you eclipse debugging config. Generally > this will default to: 192.168.99.100:8787. > > You did it right, you will be able to stop on the breakpoint inside your > HelloServlet. > > 4- Keycloak > Repeat the same procedure with your custom authenticator. Do not forget to > download the keycloak sources and include them in your the source path so > you can navigate and set break points. > > > Best regards > Mit freundlichen Gr??en > Cordialement > > Francis Pouatcha > Founder and Technical Lead Group Adorsys > > LinkedIn: http://www.linkedin.com/pub/francis-pouatcha/8/35a/542 > adorsys GmbH & Co. KG, Germany: > http://www.youtube.com/watch?v=rVRkFGUNexo&authuser=0 > Adorsys S.A., Cameroon: "African Software Competence Center" > Open https://github.com/adorsys > > Cell USA: +1 770 329 7026 > Cell Germany: +49 172 18 16 074 > Cell Cameroon: +237 51 74 71 99 > > > On Fri, Jul 1, 2016 at 2:39 AM, Rashmi Singh > wrote: > >> Thanks Thomas for your reply. I have a few questions on your response. I >> am still very new to docker, so please bear with me. >> when you say I can set env variables in docker container, would this be >> sufficient? >> >> First connect to the docker container as: >> >> docker exec -i -t keycloak bash >> Then, once I am in the container, I run the following to set env >> variables? >> >> set DEBUG_MODE=true >> set DEBUG_PORT=8787 >> exit >> Then, restart the container as: >> docker restart keycloak (keycloak is the name of my container) >> Also, how can I make sure that the env variable got correctly set in the >> docker container? From inside the container, if I run the command "env", >> should it list these new env variables if they are added successfully? >> >> Then, when you say "......default on port 8787 which you need to expose >> on your docker container or use the container interface...", what exactly >> do you mean? Do you mean some sort of port forwarding? Could you tell me w >> tohat exactly I need to do with my existing container named as "keycloak" >> >> Then, on eclipse, where you mentioned the settings for the Debug >> configurations, what should be the hostname there? would it be localhost? >> or the default machine IP of docker which is 192.168.99.100? Or it should >> be something else? >> >> >> >> On Thu, Jun 30, 2016 at 6:29 PM, Thomas Darimont < >> thomas.darimont at googlemail.com> wrote: >> >>> Hello, >>> >>> you could add -debug flag to the standalone.sh command-line or define >>> the following env variables in your docker container: >>> set DEBUG_MODE=true >>> set DEBUG_PORT=8787 >>> >>> this will start keycloak with remote debugging enabled by default on >>> port 8787 which you need to expose on your docker container or use the >>> container interface... >>> >>> you can then connect to the keycloak instance inside the docker >>> container via the remote debugger from your IDE. >>> For eclipse just go to "Debug configurations..." -> Remote Java >>> Application -> select your project with the custom authenticator -> adjust >>> hostname and port and click "debug". >>> >>> Cheers, >>> Thomas >>> >>> 2016-07-01 0:26 GMT+02:00 Rashmi Singh : >>> >>>> We have a Maven project setup on Eclipse that uses some keycloak >>>> features and we generate a jar that contains our AuthenticationProvider >>>> classes etc. >>>> We use docker for the deployment. We basically run a jboss/keycloak >>>> image there >>>> We have a shell script that has a bunch of commands to copy our project >>>> jars from local to the keycloak image on docker container like: >>>> >>>> docker cp /customauthenticator-1.0.0-SNAPSHOT.jar >>>> keycloak:/home/modules/xxx.yyy.zz.keycloak.customizations >>>> .... >>>> docker restart keycloak >>>> >>>> Running this shell script deploys everything on keycloak on docker. >>>> And so far we are just putting logs throughout our code to debug issues. >>>> We want to be able to setup a debugging environment on our eclipse. I >>>> am not sure how to achieve this when we use keycloak. Because, here we >>>> basically build our modules or authenticator jars etc and copy them to >>>> keycloak directories. So, it's not a standalone project war file that we >>>> are directly deploying to app server as such. So, then how do we put our >>>> maven project (creating jars etc) in a debug mode in eclipse? Is it >>>> possible? How? >>>> >>>> _______________________________________________ >>>> 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/20160702/4ff6b61d/attachment-0001.html From sthorger at redhat.com Mon Jul 4 03:47:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 4 Jul 2016 09:47:22 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <5776C857.2070703@redhat.com> References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> <5776C857.2070703@redhat.com> Message-ID: ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure how it would look like to an end-user. * Are these managed on a separate screen or on the protocol mappers screen? * How do users define and view scopes, including viewing what claims/mappers/roles are associated with a scope? * How does a user add/remove claims, protocol mappers and roles to a ScopeAggregatorProtocolMapper? * Do we provide one or more built-in ScopeAggregatorProtocolMapper that are configurable? I assume so and that users don't have to programatically define scopes. * Can a scope resolve to multiple ScopeAggregatorProtocolMapper? On 1 July 2016 at 21:45, Marek Posolda wrote: > Ok, I wasn't also 100% keen about using role. > > Thinking also about what Pedro mentioned before about protocol mappers. So > I wonder that instead of introduce new "scope" concept, we just reuse > protocolMappers SPI and have special impl of protocolMapper, which is able > to deal with scope parameter and aggregate other "children" protocolMappers > and roles? > > Something like this: > - There will be new ProtocolMapper implementation like > ScopeAggregatorProtocolMapper. You will define value of scope parameter > (eg. "photo" ) in the configuration of this protocolMapper. Mapper will be > ignored if scope parameter value with this name was not used. > > - You will be able to define "children" protocolMappers and "children" > roles in ScopeAggregatorProtocolMapper. > > - For each client (and clientTemplate), we will have many defined > protocolMappers, but just some subset of them are "root" mappers, which are > applied by default. The rest of mappers will be used just as "children" of > root mappers. So in client model, we might have: > client.getDefinedProtocolMappers() // all defined > client.getProtocolMappers() // just subset of defined (defacto root > mappers) > > - For example: client will have defined protocolMappers: firstName, > lastName, birthday, profile, email. Just "profile" and "email" will be root > mappers. And "profile" is ScopeAggregatorMapper for scope value "profile" > and it's children mappers are : firstName, lastName, birthday. > > So then: > -- user will send "scope=profile" . Then defacto all of "firstName", > "lastName", "birthday", "email" claims will be included in token. On > consent screen will be just "Profile" and "Email" > -- user won't send "scope=profile" . Then defacto just "email" claim will > be included (So for this example, email is always included even if not > specified by scope parameter). > > - With this concept, we are able to aggregate many various claims into > single value of "scope" and on the consent screen have just the roots. This > would fit well for the default scope values mentioned by OIDC specs. We are > also able to define mappers (claims), which will be always available even > if not specified by scope parameter. > > - For the roles, I am not 100% sure whether to include them into the > concept or not? However it seems to me that rather yes. The particular role > will be applied into token just if all of those 3 conditions are met: > 1) user is member of the role > 2) client has scope for the role (so current "scope" tab in clients will > remain as is) > 3) if role has scopePAramRequired=true, then it must be included in some > mapper (in other words, those roles are not included directly in > clientSession.getRoles , but it's the responsibility of > ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are > met). > > So again, user won't see all children roles on consent screen. Just the > parent protocolMapper. > > This will work fine with "scope=offline_access" . There will be > protocolMapper for "offline_access" parameter, which will aggregate just > one children role (the current realm role "offline_access"). The offline > token will be issued just if accessToken will have "offline_access" > permission. So if some client, doesn't need offline tokens, it can just > remove "offline_access" protocolMapper. Also if some user shouldn't be > allowed to request offline tokens, admin can remove him from the > "offline_access" role. > > - If some scope parameter is applicable for more clients, it can be > defined on clientTemplate. > > > PS: I will be on holidays and back on next Thursday 7th July. So sorry if > I won't reply immediately to next mails. > > Mare > > > > On 01/07/16 14:57, Pedro Igor Silva wrote: > >> Reading all of this makes me think it would be cleaner to introduce a >>> separate scope concept ;) >>> >>> A user doesn't have a scope - a user has roles and attributes. Re-using >>> roles >>> concept for the scope just makes it feel awkward and retrofitted. >>> >> +10000 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160704/c10d33d4/attachment.html From sthorger at redhat.com Mon Jul 4 05:36:36 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 4 Jul 2016 11:36:36 +0200 Subject: [keycloak-dev] UserFederationProvider.close() not being called In-Reply-To: References: Message-ID: Currently the user federation instances are not maintained by the Keycloak session so they're not always closed. This is not strictly a bug as it was intended to be like this. We'll probably improve this in the future and have instances managed by the Keycloak session so there's only one per session/request and it's closed when the session is closed. We're currently discussing how to do this. In the mean time enlistForClose should work. On 29 June 2016 at 23:21, Brian Watson wrote: > Would I be correct in thinking that I should call > "session.enlistForClose(provider)" in the getInstance() method of my > factory to ensure close() is called? > > _______________________________________________ > 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/20160704/e7f03dd9/attachment.html From wadahiro at gmail.com Mon Jul 4 05:51:00 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Mon, 4 Jul 2016 18:51:00 +0900 Subject: [keycloak-dev] About freemarker template file encoding Message-ID: Hello all, I am studying how to customize keycloak templates now. In that work, I have noticed the template files was loaded with the default encoding of the JVM. I suppose specifying UTF-8 encoding is better than using the default encoding because it often confuses developers. What do you think? If it's ok, I can send a pull request with the following changes. https://github.com/wadahiro/keycloak/commit/c2a3d4a9ad187c8f07cec00e89e13534adff66db Regards, -- Hiroyuki Wada, Developer, Nomura Research Institute, Ltd. From sthorger at redhat.com Mon Jul 4 06:07:07 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 4 Jul 2016 12:07:07 +0200 Subject: [keycloak-dev] About freemarker template file encoding In-Reply-To: References: Message-ID: Sounds good, please create a JIRA issue and include the JIRA issue in the commit message. On 4 July 2016 at 11:51, Hiroyuki Wada wrote: > Hello all, > > I am studying how to customize keycloak templates now. In that work, I > have noticed the template files was loaded with the default encoding > of the JVM. I suppose specifying UTF-8 encoding is better than using > the default encoding because it often confuses developers. What do you > think? > If it's ok, I can send a pull request with the following changes. > > > https://github.com/wadahiro/keycloak/commit/c2a3d4a9ad187c8f07cec00e89e13534adff66db > > Regards, > > -- > Hiroyuki Wada, > Developer, > Nomura Research Institute, Ltd. > _______________________________________________ > 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/20160704/8f66d527/attachment.html From wadahiro at gmail.com Mon Jul 4 06:33:22 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Mon, 4 Jul 2016 19:33:22 +0900 Subject: [keycloak-dev] About freemarker template file encoding In-Reply-To: References: Message-ID: Thanks for your quick response. I created a JIRA issue as follows. I'll send a pull request later. https://issues.jboss.org/browse/KEYCLOAK-3259 On Mon, Jul 4, 2016 at 7:07 PM, Stian Thorgersen wrote: > Sounds good, please create a JIRA issue and include the JIRA issue in the > commit message. > > On 4 July 2016 at 11:51, Hiroyuki Wada wrote: >> >> Hello all, >> >> I am studying how to customize keycloak templates now. In that work, I >> have noticed the template files was loaded with the default encoding >> of the JVM. I suppose specifying UTF-8 encoding is better than using >> the default encoding because it often confuses developers. What do you >> think? >> If it's ok, I can send a pull request with the following changes. >> >> >> https://github.com/wadahiro/keycloak/commit/c2a3d4a9ad187c8f07cec00e89e13534adff66db >> >> Regards, >> >> -- >> Hiroyuki Wada, >> Developer, >> Nomura Research Institute, Ltd. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From wadahiro at gmail.com Mon Jul 4 07:43:57 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Mon, 4 Jul 2016 20:43:57 +0900 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites Message-ID: Hello all, I am trying to translate all base theme messages to my country language, Japanese. And I'd like to contribute them. Before that work, I'd like to propose about the files encoding. Currently, the message files (*.properties) are loaded with ISO-8859-1 encoding. Therefore, it is necessary to convert the files by 'native2ascii' command beforehand. However we can directly read the property files with UTF-8 encoding in java 1.6 or later because 'java.util.Properties#load(java.io.Reader)' method was introduced as below. http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) So, my proposal is supporting the message files with UTF-8 encoding. I believe that it's very developers/customers friendly. In addition, we can easily review the translated messages on the github pull request view and so on. What do you think? If it's ok, I'll create a JIRA issue and create a pull request. Regards, -- Hiroyuki Wada, Developer, Nomura Research Institute, Ltd. From bruno at abstractj.org Mon Jul 4 08:37:11 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 4 Jul 2016 09:37:11 -0300 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: Message-ID: <20160704123711.GA6017@abstractj.org> It makes sense, maybe file a Jira associated with: https://issues.jboss.org/browse/KEYCLOAK-3259 ? On 2016-07-04, Hiroyuki Wada wrote: > Hello all, > > I am trying to translate all base theme messages to my country > language, Japanese. And I'd like to contribute them. Before that work, > I'd like to propose about the files encoding. > > Currently, the message files (*.properties) are loaded with ISO-8859-1 > encoding. Therefore, it is necessary to convert the files by > 'native2ascii' command beforehand. However we can directly read the > property files with UTF-8 encoding in java 1.6 or later because > 'java.util.Properties#load(java.io.Reader)' method was introduced as > below. > > http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) > > So, my proposal is supporting the message files with UTF-8 encoding. I > believe that it's very developers/customers friendly. In addition, we > can easily review the translated messages on the github pull request > view and so on. What do you think? > > If it's ok, I'll create a JIRA issue and create a pull request. > > Regards, > > -- > Hiroyuki Wada, > Developer, > Nomura Research Institute, Ltd. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From sthorger at redhat.com Mon Jul 4 09:33:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 4 Jul 2016 15:33:03 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: <20160704123711.GA6017@abstractj.org> References: <20160704123711.GA6017@abstractj.org> Message-ID: We have in the past discussed this and decided to stick with ISO-8859-1. That was probably not the best idea though. If we want to change to utf-8 we'd still need to support iso.. for backwards compatibility. On 4 July 2016 at 14:37, Bruno Oliveira wrote: > It makes sense, maybe file a Jira associated with: > https://issues.jboss.org/browse/KEYCLOAK-3259 ? > > On 2016-07-04, Hiroyuki Wada wrote: > > Hello all, > > > > I am trying to translate all base theme messages to my country > > language, Japanese. And I'd like to contribute them. Before that work, > > I'd like to propose about the files encoding. > > > > Currently, the message files (*.properties) are loaded with ISO-8859-1 > > encoding. Therefore, it is necessary to convert the files by > > 'native2ascii' command beforehand. However we can directly read the > > property files with UTF-8 encoding in java 1.6 or later because > > 'java.util.Properties#load(java.io.Reader)' method was introduced as > > below. > > > > > http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) > > > > So, my proposal is supporting the message files with UTF-8 encoding. I > > believe that it's very developers/customers friendly. In addition, we > > can easily review the translated messages on the github pull request > > view and so on. What do you think? > > > > If it's ok, I'll create a JIRA issue and create a pull request. > > > > Regards, > > > > -- > > Hiroyuki Wada, > > Developer, > > Nomura Research Institute, Ltd. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > 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/20160704/ac073239/attachment.html From psilva at redhat.com Mon Jul 4 11:10:05 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 4 Jul 2016 11:10:05 -0400 (EDT) Subject: [keycloak-dev] Tomcat 8 Arquillian Tests In-Reply-To: <1180881823.5788856.1467644858584.JavaMail.zimbra@redhat.com> Message-ID: <1494239438.5788955.1467645005286.JavaMail.zimbra@redhat.com> Hi, Is that command correct in order to get adapter tests running against a Tomcat 8 app server ? mvn -Pauth-server-wildfly -Papp-server-tomcat8 -Pexamples clean install -Dtest=Tomcat8DemoExampleAdapterTest Regards. Pedro Igor From wadahiro at gmail.com Tue Jul 5 03:49:40 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Tue, 5 Jul 2016 16:49:40 +0900 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Thanks for your comment. > If we want to change to utf-8 we'd still need to support iso.. for backwards compatibility. If we change to UTF-8, we can still read unicode codepoint like '\u00e8'. There is an incompatibility when non-ascii characters are used in message properties. The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) I think the non-ascii characters might be used in French messages like '?' so I agree to support ISO-8859-1 for backwards compatibility. To support this, I think we can add a property like "messageEncoding" in keycloak-server.json as below. Is it a good idea? "theme": { "staticMaxAge": 2592000, "cacheTemplates": true, "cacheThemes": true, "messageEncoding": "ISO-8859-1", "folder": { "dir": "${jboss.home.dir}/themes" } }, Regards, On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen wrote: > We have in the past discussed this and decided to stick with ISO-8859-1. > That was probably not the best idea though. If we want to change to utf-8 > we'd still need to support iso.. for backwards compatibility. > > On 4 July 2016 at 14:37, Bruno Oliveira wrote: >> >> It makes sense, maybe file a Jira associated with: >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >> >> On 2016-07-04, Hiroyuki Wada wrote: >> > Hello all, >> > >> > I am trying to translate all base theme messages to my country >> > language, Japanese. And I'd like to contribute them. Before that work, >> > I'd like to propose about the files encoding. >> > >> > Currently, the message files (*.properties) are loaded with ISO-8859-1 >> > encoding. Therefore, it is necessary to convert the files by >> > 'native2ascii' command beforehand. However we can directly read the >> > property files with UTF-8 encoding in java 1.6 or later because >> > 'java.util.Properties#load(java.io.Reader)' method was introduced as >> > below. >> > >> > >> > http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >> > >> > So, my proposal is supporting the message files with UTF-8 encoding. I >> > believe that it's very developers/customers friendly. In addition, we >> > can easily review the translated messages on the github pull request >> > view and so on. What do you think? >> > >> > If it's ok, I'll create a JIRA issue and create a pull request. >> > >> > Regards, >> > >> > -- >> > Hiroyuki Wada, >> > Developer, >> > Nomura Research Institute, Ltd. >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From sthorger at redhat.com Wed Jul 6 02:04:34 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 6 Jul 2016 08:04:34 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Both iso-8859-1 and utf-8 message bundles should be able to co-exist. We can allow specifying the encoding in a comment on the first line like this: # encoding=utf-8 key=value # encoding=iso-8859-1 key=value If the first line in the file doesn't contain the comment with the encoding then we should default to iso-8859-1 for backwards compatibility On 5 July 2016 at 09:49, Hiroyuki Wada wrote: > Thanks for your comment. > > > If we want to change to utf-8 we'd still need to support iso.. for > backwards compatibility. > > If we change to UTF-8, we can still read unicode codepoint like '\u00e8'. > There is an incompatibility when non-ascii characters are used in > message properties. > The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage > layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) > > I think the non-ascii characters might be used in French messages like > '?' so I agree to support ISO-8859-1 for backwards compatibility. > To support this, I think we can add a property like "messageEncoding" > in keycloak-server.json as below. Is it a good idea? > > "theme": { > "staticMaxAge": 2592000, > "cacheTemplates": true, > "cacheThemes": true, > "messageEncoding": "ISO-8859-1", > "folder": { > "dir": "${jboss.home.dir}/themes" > } > }, > > Regards, > > On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen > wrote: > > We have in the past discussed this and decided to stick with ISO-8859-1. > > That was probably not the best idea though. If we want to change to utf-8 > > we'd still need to support iso.. for backwards compatibility. > > > > On 4 July 2016 at 14:37, Bruno Oliveira wrote: > >> > >> It makes sense, maybe file a Jira associated with: > >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? > >> > >> On 2016-07-04, Hiroyuki Wada wrote: > >> > Hello all, > >> > > >> > I am trying to translate all base theme messages to my country > >> > language, Japanese. And I'd like to contribute them. Before that work, > >> > I'd like to propose about the files encoding. > >> > > >> > Currently, the message files (*.properties) are loaded with ISO-8859-1 > >> > encoding. Therefore, it is necessary to convert the files by > >> > 'native2ascii' command beforehand. However we can directly read the > >> > property files with UTF-8 encoding in java 1.6 or later because > >> > 'java.util.Properties#load(java.io.Reader)' method was introduced as > >> > below. > >> > > >> > > >> > > http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) > >> > > >> > So, my proposal is supporting the message files with UTF-8 encoding. I > >> > believe that it's very developers/customers friendly. In addition, we > >> > can easily review the translated messages on the github pull request > >> > view and so on. What do you think? > >> > > >> > If it's ok, I'll create a JIRA issue and create a pull request. > >> > > >> > Regards, > >> > > >> > -- > >> > Hiroyuki Wada, > >> > Developer, > >> > Nomura Research Institute, Ltd. > >> > _______________________________________________ > >> > keycloak-dev mailing list > >> > keycloak-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> _______________________________________________ > >> 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/20160706/7c4f0f6f/attachment-0001.html From thomas.raehalme at aitiofinland.com Wed Jul 6 02:32:26 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 6 Jul 2016 09:32:26 +0300 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Please correct me if I am wrong, but I have been under the impression that Java .properties files should always use encoding ISO-8859-1. Characters not present in ISO-8859-1 can be written in \uxxxx. Won't it make things confusing to developers if another encoding is used here instead? https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- If alternate encodings are desired how about supporting the XML format of Properties? Best regards, Thomas On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen wrote: > Both iso-8859-1 and utf-8 message bundles should be able to co-exist. > > We can allow specifying the encoding in a comment on the first line like > this: > > # encoding=utf-8 > key=value > > # encoding=iso-8859-1 > key=value > > If the first line in the file doesn't contain the comment with the > encoding then we should default to iso-8859-1 for backwards compatibility > > On 5 July 2016 at 09:49, Hiroyuki Wada wrote: > >> Thanks for your comment. >> >> > If we want to change to utf-8 we'd still need to support iso.. for >> backwards compatibility. >> >> If we change to UTF-8, we can still read unicode codepoint like '\u00e8'. >> There is an incompatibility when non-ascii characters are used in >> message properties. >> The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage >> layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >> >> I think the non-ascii characters might be used in French messages like >> '?' so I agree to support ISO-8859-1 for backwards compatibility. >> To support this, I think we can add a property like "messageEncoding" >> in keycloak-server.json as below. Is it a good idea? >> >> "theme": { >> "staticMaxAge": 2592000, >> "cacheTemplates": true, >> "cacheThemes": true, >> "messageEncoding": "ISO-8859-1", >> "folder": { >> "dir": "${jboss.home.dir}/themes" >> } >> }, >> >> Regards, >> >> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >> wrote: >> > We have in the past discussed this and decided to stick with ISO-8859-1. >> > That was probably not the best idea though. If we want to change to >> utf-8 >> > we'd still need to support iso.. for backwards compatibility. >> > >> > On 4 July 2016 at 14:37, Bruno Oliveira wrote: >> >> >> >> It makes sense, maybe file a Jira associated with: >> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >> >> >> >> On 2016-07-04, Hiroyuki Wada wrote: >> >> > Hello all, >> >> > >> >> > I am trying to translate all base theme messages to my country >> >> > language, Japanese. And I'd like to contribute them. Before that >> work, >> >> > I'd like to propose about the files encoding. >> >> > >> >> > Currently, the message files (*.properties) are loaded with >> ISO-8859-1 >> >> > encoding. Therefore, it is necessary to convert the files by >> >> > 'native2ascii' command beforehand. However we can directly read the >> >> > property files with UTF-8 encoding in java 1.6 or later because >> >> > 'java.util.Properties#load(java.io.Reader)' method was introduced as >> >> > below. >> >> > >> >> > >> >> > >> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >> >> > >> >> > So, my proposal is supporting the message files with UTF-8 encoding. >> I >> >> > believe that it's very developers/customers friendly. In addition, we >> >> > can easily review the translated messages on the github pull request >> >> > view and so on. What do you think? >> >> > >> >> > If it's ok, I'll create a JIRA issue and create a pull request. >> >> > >> >> > Regards, >> >> > >> >> > -- >> >> > Hiroyuki Wada, >> >> > Developer, >> >> > Nomura Research Institute, Ltd. >> >> > _______________________________________________ >> >> > keycloak-dev mailing list >> >> > keycloak-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> >> >> >> abstractj >> >> PGP: 0x84DC9914 >> >> _______________________________________________ >> >> 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/20160706/ada2c33e/attachment.html From sthorger at redhat.com Wed Jul 6 02:41:56 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 6 Jul 2016 08:41:56 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Java properties file does by default use iso-8859-1, but that's far from elegant for some languages. I don't see any issues with supporting utf-8 with a header like I suggested. It would be fairly easy to implement. Java does use utf-8 by default for XML property files, but I don't think that's a very nice format to edit the messages in. On 6 July 2016 at 08:32, Thomas Raehalme wrote: > Please correct me if I am wrong, but I have been under the impression that > Java .properties files should always use encoding ISO-8859-1. Characters > not present in ISO-8859-1 can be written in \uxxxx. Won't it make things > confusing to developers if another encoding is used here instead? > > > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- > > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- > > If alternate encodings are desired how about supporting the XML format of > Properties? > > Best regards, > Thomas > > > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen > wrote: > >> Both iso-8859-1 and utf-8 message bundles should be able to co-exist. >> >> We can allow specifying the encoding in a comment on the first line like >> this: >> >> # encoding=utf-8 >> key=value >> >> # encoding=iso-8859-1 >> key=value >> >> If the first line in the file doesn't contain the comment with the >> encoding then we should default to iso-8859-1 for backwards compatibility >> >> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >> >>> Thanks for your comment. >>> >>> > If we want to change to utf-8 we'd still need to support iso.. for >>> backwards compatibility. >>> >>> If we change to UTF-8, we can still read unicode codepoint like '\u00e8'. >>> There is an incompatibility when non-ascii characters are used in >>> message properties. >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage >>> layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>> >>> I think the non-ascii characters might be used in French messages like >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >>> To support this, I think we can add a property like "messageEncoding" >>> in keycloak-server.json as below. Is it a good idea? >>> >>> "theme": { >>> "staticMaxAge": 2592000, >>> "cacheTemplates": true, >>> "cacheThemes": true, >>> "messageEncoding": "ISO-8859-1", >>> "folder": { >>> "dir": "${jboss.home.dir}/themes" >>> } >>> }, >>> >>> Regards, >>> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>> wrote: >>> > We have in the past discussed this and decided to stick with >>> ISO-8859-1. >>> > That was probably not the best idea though. If we want to change to >>> utf-8 >>> > we'd still need to support iso.. for backwards compatibility. >>> > >>> > On 4 July 2016 at 14:37, Bruno Oliveira wrote: >>> >> >>> >> It makes sense, maybe file a Jira associated with: >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>> >> > Hello all, >>> >> > >>> >> > I am trying to translate all base theme messages to my country >>> >> > language, Japanese. And I'd like to contribute them. Before that >>> work, >>> >> > I'd like to propose about the files encoding. >>> >> > >>> >> > Currently, the message files (*.properties) are loaded with >>> ISO-8859-1 >>> >> > encoding. Therefore, it is necessary to convert the files by >>> >> > 'native2ascii' command beforehand. However we can directly read the >>> >> > property files with UTF-8 encoding in java 1.6 or later because >>> >> > 'java.util.Properties#load(java.io.Reader)' method was introduced as >>> >> > below. >>> >> > >>> >> > >>> >> > >>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>> >> > >>> >> > So, my proposal is supporting the message files with UTF-8 >>> encoding. I >>> >> > believe that it's very developers/customers friendly. In addition, >>> we >>> >> > can easily review the translated messages on the github pull request >>> >> > view and so on. What do you think? >>> >> > >>> >> > If it's ok, I'll create a JIRA issue and create a pull request. >>> >> > >>> >> > Regards, >>> >> > >>> >> > -- >>> >> > Hiroyuki Wada, >>> >> > Developer, >>> >> > Nomura Research Institute, Ltd. >>> >> > _______________________________________________ >>> >> > keycloak-dev mailing list >>> >> > keycloak-dev at lists.jboss.org >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >>> >> -- >>> >> >>> >> abstractj >>> >> PGP: 0x84DC9914 >>> >> _______________________________________________ >>> >> 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/20160706/6c918498/attachment-0001.html From sthorger at redhat.com Wed Jul 6 02:43:34 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 6 Jul 2016 08:43:34 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Actually, just thought of a con for encoding header in properties file. IDEs would not honor it and would in most cases believe the file is iso-8859-1. On 6 July 2016 at 08:41, Stian Thorgersen wrote: > Java properties file does by default use iso-8859-1, but that's far from > elegant for some languages. I don't see any issues with supporting utf-8 > with a header like I suggested. It would be fairly easy to implement. Java > does use utf-8 by default for XML property files, but I don't think that's > a very nice format to edit the messages in. > > On 6 July 2016 at 08:32, Thomas Raehalme > wrote: > >> Please correct me if I am wrong, but I have been under the impression >> that Java .properties files should always use encoding ISO-8859-1. >> Characters not present in ISO-8859-1 can be written in \uxxxx. Won't it >> make things confusing to developers if another encoding is used here >> instead? >> >> >> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >> >> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >> >> If alternate encodings are desired how about supporting the XML format of >> Properties? >> >> Best regards, >> Thomas >> >> >> On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen >> wrote: >> >>> Both iso-8859-1 and utf-8 message bundles should be able to co-exist. >>> >>> We can allow specifying the encoding in a comment on the first line like >>> this: >>> >>> # encoding=utf-8 >>> key=value >>> >>> # encoding=iso-8859-1 >>> key=value >>> >>> If the first line in the file doesn't contain the comment with the >>> encoding then we should default to iso-8859-1 for backwards compatibility >>> >>> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >>> >>>> Thanks for your comment. >>>> >>>> > If we want to change to utf-8 we'd still need to support iso.. for >>>> backwards compatibility. >>>> >>>> If we change to UTF-8, we can still read unicode codepoint like >>>> '\u00e8'. >>>> There is an incompatibility when non-ascii characters are used in >>>> message properties. >>>> The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage >>>> layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>> >>>> I think the non-ascii characters might be used in French messages like >>>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >>>> To support this, I think we can add a property like "messageEncoding" >>>> in keycloak-server.json as below. Is it a good idea? >>>> >>>> "theme": { >>>> "staticMaxAge": 2592000, >>>> "cacheTemplates": true, >>>> "cacheThemes": true, >>>> "messageEncoding": "ISO-8859-1", >>>> "folder": { >>>> "dir": "${jboss.home.dir}/themes" >>>> } >>>> }, >>>> >>>> Regards, >>>> >>>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>> wrote: >>>> > We have in the past discussed this and decided to stick with >>>> ISO-8859-1. >>>> > That was probably not the best idea though. If we want to change to >>>> utf-8 >>>> > we'd still need to support iso.. for backwards compatibility. >>>> > >>>> > On 4 July 2016 at 14:37, Bruno Oliveira wrote: >>>> >> >>>> >> It makes sense, maybe file a Jira associated with: >>>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>> >> >>>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>> >> > Hello all, >>>> >> > >>>> >> > I am trying to translate all base theme messages to my country >>>> >> > language, Japanese. And I'd like to contribute them. Before that >>>> work, >>>> >> > I'd like to propose about the files encoding. >>>> >> > >>>> >> > Currently, the message files (*.properties) are loaded with >>>> ISO-8859-1 >>>> >> > encoding. Therefore, it is necessary to convert the files by >>>> >> > 'native2ascii' command beforehand. However we can directly read the >>>> >> > property files with UTF-8 encoding in java 1.6 or later because >>>> >> > 'java.util.Properties#load(java.io.Reader)' method was introduced >>>> as >>>> >> > below. >>>> >> > >>>> >> > >>>> >> > >>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>> >> > >>>> >> > So, my proposal is supporting the message files with UTF-8 >>>> encoding. I >>>> >> > believe that it's very developers/customers friendly. In addition, >>>> we >>>> >> > can easily review the translated messages on the github pull >>>> request >>>> >> > view and so on. What do you think? >>>> >> > >>>> >> > If it's ok, I'll create a JIRA issue and create a pull request. >>>> >> > >>>> >> > Regards, >>>> >> > >>>> >> > -- >>>> >> > Hiroyuki Wada, >>>> >> > Developer, >>>> >> > Nomura Research Institute, Ltd. >>>> >> > _______________________________________________ >>>> >> > keycloak-dev mailing list >>>> >> > keycloak-dev at lists.jboss.org >>>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> >>>> >> -- >>>> >> >>>> >> abstractj >>>> >> PGP: 0x84DC9914 >>>> >> _______________________________________________ >>>> >> 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/20160706/95e3a37a/attachment.html From thomas.raehalme at aitiofinland.com Wed Jul 6 03:07:20 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 6 Jul 2016 10:07:20 +0300 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: I didn't say using ISO-8859-1 with .properties was elegant, just the way it is :-) For XML files UTF-8 is the default in the specification: https://www.w3.org/TR/REC-xml/#sec-guessing Maintaining XML files is not fun either, but it does solve the encoding issue. Best regards, Thomas On Wed, Jul 6, 2016 at 9:43 AM, Stian Thorgersen wrote: > Actually, just thought of a con for encoding header in properties file. > IDEs would not honor it and would in most cases believe the file is > iso-8859-1. > > On 6 July 2016 at 08:41, Stian Thorgersen wrote: > >> Java properties file does by default use iso-8859-1, but that's far from >> elegant for some languages. I don't see any issues with supporting utf-8 >> with a header like I suggested. It would be fairly easy to implement. Java >> does use utf-8 by default for XML property files, but I don't think that's >> a very nice format to edit the messages in. >> >> On 6 July 2016 at 08:32, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >> >>> Please correct me if I am wrong, but I have been under the impression >>> that Java .properties files should always use encoding ISO-8859-1. >>> Characters not present in ISO-8859-1 can be written in \uxxxx. Won't it >>> make things confusing to developers if another encoding is used here >>> instead? >>> >>> >>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>> >>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>> >>> If alternate encodings are desired how about supporting the XML format >>> of Properties? >>> >>> Best regards, >>> Thomas >>> >>> >>> On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen >>> wrote: >>> >>>> Both iso-8859-1 and utf-8 message bundles should be able to co-exist. >>>> >>>> We can allow specifying the encoding in a comment on the first line >>>> like this: >>>> >>>> # encoding=utf-8 >>>> key=value >>>> >>>> # encoding=iso-8859-1 >>>> key=value >>>> >>>> If the first line in the file doesn't contain the comment with the >>>> encoding then we should default to iso-8859-1 for backwards compatibility >>>> >>>> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >>>> >>>>> Thanks for your comment. >>>>> >>>>> > If we want to change to utf-8 we'd still need to support iso.. for >>>>> backwards compatibility. >>>>> >>>>> If we change to UTF-8, we can still read unicode codepoint like >>>>> '\u00e8'. >>>>> There is an incompatibility when non-ascii characters are used in >>>>> message properties. >>>>> The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage >>>>> layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>> >>>>> I think the non-ascii characters might be used in French messages like >>>>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >>>>> To support this, I think we can add a property like "messageEncoding" >>>>> in keycloak-server.json as below. Is it a good idea? >>>>> >>>>> "theme": { >>>>> "staticMaxAge": 2592000, >>>>> "cacheTemplates": true, >>>>> "cacheThemes": true, >>>>> "messageEncoding": "ISO-8859-1", >>>>> "folder": { >>>>> "dir": "${jboss.home.dir}/themes" >>>>> } >>>>> }, >>>>> >>>>> Regards, >>>>> >>>>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>> wrote: >>>>> > We have in the past discussed this and decided to stick with >>>>> ISO-8859-1. >>>>> > That was probably not the best idea though. If we want to change to >>>>> utf-8 >>>>> > we'd still need to support iso.. for backwards compatibility. >>>>> > >>>>> > On 4 July 2016 at 14:37, Bruno Oliveira wrote: >>>>> >> >>>>> >> It makes sense, maybe file a Jira associated with: >>>>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>> >> >>>>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>> >> > Hello all, >>>>> >> > >>>>> >> > I am trying to translate all base theme messages to my country >>>>> >> > language, Japanese. And I'd like to contribute them. Before that >>>>> work, >>>>> >> > I'd like to propose about the files encoding. >>>>> >> > >>>>> >> > Currently, the message files (*.properties) are loaded with >>>>> ISO-8859-1 >>>>> >> > encoding. Therefore, it is necessary to convert the files by >>>>> >> > 'native2ascii' command beforehand. However we can directly read >>>>> the >>>>> >> > property files with UTF-8 encoding in java 1.6 or later because >>>>> >> > 'java.util.Properties#load(java.io.Reader)' method was introduced >>>>> as >>>>> >> > below. >>>>> >> > >>>>> >> > >>>>> >> > >>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>> >> > >>>>> >> > So, my proposal is supporting the message files with UTF-8 >>>>> encoding. I >>>>> >> > believe that it's very developers/customers friendly. In >>>>> addition, we >>>>> >> > can easily review the translated messages on the github pull >>>>> request >>>>> >> > view and so on. What do you think? >>>>> >> > >>>>> >> > If it's ok, I'll create a JIRA issue and create a pull request. >>>>> >> > >>>>> >> > Regards, >>>>> >> > >>>>> >> > -- >>>>> >> > Hiroyuki Wada, >>>>> >> > Developer, >>>>> >> > Nomura Research Institute, Ltd. >>>>> >> > _______________________________________________ >>>>> >> > keycloak-dev mailing list >>>>> >> > keycloak-dev at lists.jboss.org >>>>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >> >>>>> >> -- >>>>> >> >>>>> >> abstractj >>>>> >> PGP: 0x84DC9914 >>>>> >> _______________________________________________ >>>>> >> 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/20160706/47c304f7/attachment-0001.html From sthorger at redhat.com Wed Jul 6 03:36:00 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 6 Jul 2016 09:36:00 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: On 6 July 2016 at 09:07, Thomas Raehalme wrote: > I didn't say using ISO-8859-1 with .properties was elegant, just the way > it is :-) > The fact that it's the default doesn't mean it has to be the only way ;) > > For XML files UTF-8 is the default in the specification: > https://www.w3.org/TR/REC-xml/#sec-guessing > Maintaining XML files is not fun either, but it does solve the encoding > issue. > > Best regards, > Thomas > > > On Wed, Jul 6, 2016 at 9:43 AM, Stian Thorgersen > wrote: > >> Actually, just thought of a con for encoding header in properties file. >> IDEs would not honor it and would in most cases believe the file is >> iso-8859-1. >> >> On 6 July 2016 at 08:41, Stian Thorgersen wrote: >> >>> Java properties file does by default use iso-8859-1, but that's far from >>> elegant for some languages. I don't see any issues with supporting utf-8 >>> with a header like I suggested. It would be fairly easy to implement. Java >>> does use utf-8 by default for XML property files, but I don't think that's >>> a very nice format to edit the messages in. >>> >>> On 6 July 2016 at 08:32, Thomas Raehalme < >>> thomas.raehalme at aitiofinland.com> wrote: >>> >>>> Please correct me if I am wrong, but I have been under the impression >>>> that Java .properties files should always use encoding ISO-8859-1. >>>> Characters not present in ISO-8859-1 can be written in \uxxxx. Won't it >>>> make things confusing to developers if another encoding is used here >>>> instead? >>>> >>>> >>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>> >>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>> >>>> If alternate encodings are desired how about supporting the XML format >>>> of Properties? >>>> >>>> Best regards, >>>> Thomas >>>> >>>> >>>> On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen >>>> wrote: >>>> >>>>> Both iso-8859-1 and utf-8 message bundles should be able to co-exist. >>>>> >>>>> We can allow specifying the encoding in a comment on the first line >>>>> like this: >>>>> >>>>> # encoding=utf-8 >>>>> key=value >>>>> >>>>> # encoding=iso-8859-1 >>>>> key=value >>>>> >>>>> If the first line in the file doesn't contain the comment with the >>>>> encoding then we should default to iso-8859-1 for backwards compatibility >>>>> >>>>> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >>>>> >>>>>> Thanks for your comment. >>>>>> >>>>>> > If we want to change to utf-8 we'd still need to support iso.. for >>>>>> backwards compatibility. >>>>>> >>>>>> If we change to UTF-8, we can still read unicode codepoint like >>>>>> '\u00e8'. >>>>>> There is an incompatibility when non-ascii characters are used in >>>>>> message properties. >>>>>> The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage >>>>>> layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout >>>>>> ) >>>>>> >>>>>> I think the non-ascii characters might be used in French messages like >>>>>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >>>>>> To support this, I think we can add a property like "messageEncoding" >>>>>> in keycloak-server.json as below. Is it a good idea? >>>>>> >>>>>> "theme": { >>>>>> "staticMaxAge": 2592000, >>>>>> "cacheTemplates": true, >>>>>> "cacheThemes": true, >>>>>> "messageEncoding": "ISO-8859-1", >>>>>> "folder": { >>>>>> "dir": "${jboss.home.dir}/themes" >>>>>> } >>>>>> }, >>>>>> >>>>>> Regards, >>>>>> >>>>>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen < >>>>>> sthorger at redhat.com> wrote: >>>>>> > We have in the past discussed this and decided to stick with >>>>>> ISO-8859-1. >>>>>> > That was probably not the best idea though. If we want to change to >>>>>> utf-8 >>>>>> > we'd still need to support iso.. for backwards compatibility. >>>>>> > >>>>>> > On 4 July 2016 at 14:37, Bruno Oliveira >>>>>> wrote: >>>>>> >> >>>>>> >> It makes sense, maybe file a Jira associated with: >>>>>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>> >> >>>>>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>> >> > Hello all, >>>>>> >> > >>>>>> >> > I am trying to translate all base theme messages to my country >>>>>> >> > language, Japanese. And I'd like to contribute them. Before that >>>>>> work, >>>>>> >> > I'd like to propose about the files encoding. >>>>>> >> > >>>>>> >> > Currently, the message files (*.properties) are loaded with >>>>>> ISO-8859-1 >>>>>> >> > encoding. Therefore, it is necessary to convert the files by >>>>>> >> > 'native2ascii' command beforehand. However we can directly read >>>>>> the >>>>>> >> > property files with UTF-8 encoding in java 1.6 or later because >>>>>> >> > 'java.util.Properties#load(java.io.Reader)' method was >>>>>> introduced as >>>>>> >> > below. >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>> >> > >>>>>> >> > So, my proposal is supporting the message files with UTF-8 >>>>>> encoding. I >>>>>> >> > believe that it's very developers/customers friendly. In >>>>>> addition, we >>>>>> >> > can easily review the translated messages on the github pull >>>>>> request >>>>>> >> > view and so on. What do you think? >>>>>> >> > >>>>>> >> > If it's ok, I'll create a JIRA issue and create a pull request. >>>>>> >> > >>>>>> >> > Regards, >>>>>> >> > >>>>>> >> > -- >>>>>> >> > Hiroyuki Wada, >>>>>> >> > Developer, >>>>>> >> > Nomura Research Institute, Ltd. >>>>>> >> > _______________________________________________ >>>>>> >> > keycloak-dev mailing list >>>>>> >> > keycloak-dev at lists.jboss.org >>>>>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >> >>>>>> >> -- >>>>>> >> >>>>>> >> abstractj >>>>>> >> PGP: 0x84DC9914 >>>>>> >> _______________________________________________ >>>>>> >> 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/20160706/0074ccde/attachment.html From wadahiro at gmail.com Wed Jul 6 05:40:44 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Wed, 6 Jul 2016 18:40:44 +0900 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: I think it was true before Java 1.6 because Java standard library (java.util.ResourceBundle or java.util.Properties) only supported ISO-8859-1 encoding file. But they support any encoding after Java 1.6. There are some frameworks which can read .properties with any encoding. For example, Spring Framework can read .properties with any encoding. I think it's very useful to read UTF-8 directly for multibyte language country. On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme wrote: > Please correct me if I am wrong, but I have been under the impression that > Java .properties files should always use encoding ISO-8859-1. Characters not > present in ISO-8859-1 can be written in \uxxxx. Won't it make things > confusing to developers if another encoding is used here instead? > > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- > > If alternate encodings are desired how about supporting the XML format of > Properties? > > Best regards, > Thomas > > > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen > wrote: >> >> Both iso-8859-1 and utf-8 message bundles should be able to co-exist. >> >> We can allow specifying the encoding in a comment on the first line like >> this: >> >> # encoding=utf-8 >> key=value >> >> # encoding=iso-8859-1 >> key=value >> >> If the first line in the file doesn't contain the comment with the >> encoding then we should default to iso-8859-1 for backwards compatibility >> >> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >>> >>> Thanks for your comment. >>> >>> > If we want to change to utf-8 we'd still need to support iso.. for >>> > backwards compatibility. >>> >>> If we change to UTF-8, we can still read unicode codepoint like '\u00e8'. >>> There is an incompatibility when non-ascii characters are used in >>> message properties. >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage >>> layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>> >>> I think the non-ascii characters might be used in French messages like >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >>> To support this, I think we can add a property like "messageEncoding" >>> in keycloak-server.json as below. Is it a good idea? >>> >>> "theme": { >>> "staticMaxAge": 2592000, >>> "cacheTemplates": true, >>> "cacheThemes": true, >>> "messageEncoding": "ISO-8859-1", >>> "folder": { >>> "dir": "${jboss.home.dir}/themes" >>> } >>> }, >>> >>> Regards, >>> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>> wrote: >>> > We have in the past discussed this and decided to stick with >>> > ISO-8859-1. >>> > That was probably not the best idea though. If we want to change to >>> > utf-8 >>> > we'd still need to support iso.. for backwards compatibility. >>> > >>> > On 4 July 2016 at 14:37, Bruno Oliveira wrote: >>> >> >>> >> It makes sense, maybe file a Jira associated with: >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>> >> > Hello all, >>> >> > >>> >> > I am trying to translate all base theme messages to my country >>> >> > language, Japanese. And I'd like to contribute them. Before that >>> >> > work, >>> >> > I'd like to propose about the files encoding. >>> >> > >>> >> > Currently, the message files (*.properties) are loaded with >>> >> > ISO-8859-1 >>> >> > encoding. Therefore, it is necessary to convert the files by >>> >> > 'native2ascii' command beforehand. However we can directly read the >>> >> > property files with UTF-8 encoding in java 1.6 or later because >>> >> > 'java.util.Properties#load(java.io.Reader)' method was introduced as >>> >> > below. >>> >> > >>> >> > >>> >> > >>> >> > http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>> >> > >>> >> > So, my proposal is supporting the message files with UTF-8 encoding. >>> >> > I >>> >> > believe that it's very developers/customers friendly. In addition, >>> >> > we >>> >> > can easily review the translated messages on the github pull request >>> >> > view and so on. What do you think? >>> >> > >>> >> > If it's ok, I'll create a JIRA issue and create a pull request. >>> >> > >>> >> > Regards, >>> >> > >>> >> > -- >>> >> > Hiroyuki Wada, >>> >> > Developer, >>> >> > Nomura Research Institute, Ltd. >>> >> > _______________________________________________ >>> >> > keycloak-dev mailing list >>> >> > keycloak-dev at lists.jboss.org >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >>> >> -- >>> >> >>> >> abstractj >>> >> PGP: 0x84DC9914 >>> >> _______________________________________________ >>> >> 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 > > > From thomas.raehalme at aitiofinland.com Wed Jul 6 05:53:48 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 6 Jul 2016 12:53:48 +0300 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: >From the javadoc of java.util.ResourceBundle the encoding for .properties is still expected to be ISO-8859-1: Constructing a PropertyResourceBundle instance from an InputStream requires > that the input stream be encoded in ISO-8859-1. In that case, characters > that cannot be represented in ISO-8859-1 encoding must be represented by > Unicode Escapes as defined in section 3.3 of The Java? Language > Specification whereas the other constructor which takes a Reader does not > have that limitation. > https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html I understand that Spring allows one to read .properties using any encoding, but you need to specify the encoding in Spring configuration external to the .properties file. In my opinion it would cause unnecessary confusion amongst developers to use any other encoding than the one defined by the official documentation for Properties. Best regards, Thomas On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada wrote: > I think it was true before Java 1.6 because Java standard library > (java.util.ResourceBundle or java.util.Properties) only supported > ISO-8859-1 encoding file. > But they support any encoding after Java 1.6. There are some > frameworks which can read .properties with any encoding. For example, > Spring Framework can read .properties with any encoding. I think it's > very useful to read UTF-8 directly for multibyte language country. > > On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme > wrote: > > Please correct me if I am wrong, but I have been under the impression > that > > Java .properties files should always use encoding ISO-8859-1. Characters > not > > present in ISO-8859-1 can be written in \uxxxx. Won't it make things > > confusing to developers if another encoding is used here instead? > > > > > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- > > > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- > > > > If alternate encodings are desired how about supporting the XML format of > > Properties? > > > > Best regards, > > Thomas > > > > > > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen > > wrote: > >> > >> Both iso-8859-1 and utf-8 message bundles should be able to co-exist. > >> > >> We can allow specifying the encoding in a comment on the first line like > >> this: > >> > >> # encoding=utf-8 > >> key=value > >> > >> # encoding=iso-8859-1 > >> key=value > >> > >> If the first line in the file doesn't contain the comment with the > >> encoding then we should default to iso-8859-1 for backwards > compatibility > >> > >> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: > >>> > >>> Thanks for your comment. > >>> > >>> > If we want to change to utf-8 we'd still need to support iso.. for > >>> > backwards compatibility. > >>> > >>> If we change to UTF-8, we can still read unicode codepoint like > '\u00e8'. > >>> There is an incompatibility when non-ascii characters are used in > >>> message properties. > >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage > >>> layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) > >>> > >>> I think the non-ascii characters might be used in French messages like > >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. > >>> To support this, I think we can add a property like "messageEncoding" > >>> in keycloak-server.json as below. Is it a good idea? > >>> > >>> "theme": { > >>> "staticMaxAge": 2592000, > >>> "cacheTemplates": true, > >>> "cacheThemes": true, > >>> "messageEncoding": "ISO-8859-1", > >>> "folder": { > >>> "dir": "${jboss.home.dir}/themes" > >>> } > >>> }, > >>> > >>> Regards, > >>> > >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen > > >>> wrote: > >>> > We have in the past discussed this and decided to stick with > >>> > ISO-8859-1. > >>> > That was probably not the best idea though. If we want to change to > >>> > utf-8 > >>> > we'd still need to support iso.. for backwards compatibility. > >>> > > >>> > On 4 July 2016 at 14:37, Bruno Oliveira wrote: > >>> >> > >>> >> It makes sense, maybe file a Jira associated with: > >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? > >>> >> > >>> >> On 2016-07-04, Hiroyuki Wada wrote: > >>> >> > Hello all, > >>> >> > > >>> >> > I am trying to translate all base theme messages to my country > >>> >> > language, Japanese. And I'd like to contribute them. Before that > >>> >> > work, > >>> >> > I'd like to propose about the files encoding. > >>> >> > > >>> >> > Currently, the message files (*.properties) are loaded with > >>> >> > ISO-8859-1 > >>> >> > encoding. Therefore, it is necessary to convert the files by > >>> >> > 'native2ascii' command beforehand. However we can directly read > the > >>> >> > property files with UTF-8 encoding in java 1.6 or later because > >>> >> > 'java.util.Properties#load(java.io.Reader)' method was introduced > as > >>> >> > below. > >>> >> > > >>> >> > > >>> >> > > >>> >> > > http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) > >>> >> > > >>> >> > So, my proposal is supporting the message files with UTF-8 > encoding. > >>> >> > I > >>> >> > believe that it's very developers/customers friendly. In addition, > >>> >> > we > >>> >> > can easily review the translated messages on the github pull > request > >>> >> > view and so on. What do you think? > >>> >> > > >>> >> > If it's ok, I'll create a JIRA issue and create a pull request. > >>> >> > > >>> >> > Regards, > >>> >> > > >>> >> > -- > >>> >> > Hiroyuki Wada, > >>> >> > Developer, > >>> >> > Nomura Research Institute, Ltd. > >>> >> > _______________________________________________ > >>> >> > keycloak-dev mailing list > >>> >> > keycloak-dev at lists.jboss.org > >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> >> > >>> >> -- > >>> >> > >>> >> abstractj > >>> >> PGP: 0x84DC9914 > >>> >> _______________________________________________ > >>> >> 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/20160706/4b2d8fae/attachment-0001.html From wadahiro at gmail.com Wed Jul 6 06:30:35 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Wed, 6 Jul 2016 19:30:35 +0900 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme wrote: > From the javadoc of java.util.ResourceBundle the encoding for .properties is > still expected to be ISO-8859-1: > >> Constructing a PropertyResourceBundle instance from an InputStream >> requires that the input stream be encoded in ISO-8859-1. In that case, >> characters that cannot be represented in ISO-8859-1 encoding must be >> represented by Unicode Escapes as defined in section 3.3 of The Java? >> Language Specification whereas the other constructor which takes a Reader >> does not have that limitation. It's a case of using constructor which takes an InputStream. It says we can use any encoding when we use the other constructor which takes a Reader. I understand your concern. So what do you think supporting utf-8 with a header like Stian suggested? I think it can avoid confusion because the encoding is noted in the file itself... Regards, > https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html > > I understand that Spring allows one to read .properties using any encoding, > but you need to specify the encoding in Spring configuration external to the > .properties file. > > In my opinion it would cause unnecessary confusion amongst developers to use > any other encoding than the one defined by the official documentation for > Properties. > > Best regards, > Thomas > > > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada wrote: >> >> I think it was true before Java 1.6 because Java standard library >> (java.util.ResourceBundle or java.util.Properties) only supported >> ISO-8859-1 encoding file. >> But they support any encoding after Java 1.6. There are some >> frameworks which can read .properties with any encoding. For example, >> Spring Framework can read .properties with any encoding. I think it's >> very useful to read UTF-8 directly for multibyte language country. >> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >> wrote: >> > Please correct me if I am wrong, but I have been under the impression >> > that >> > Java .properties files should always use encoding ISO-8859-1. Characters >> > not >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make things >> > confusing to developers if another encoding is used here instead? >> > >> > >> > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >> > >> > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >> > >> > If alternate encodings are desired how about supporting the XML format >> > of >> > Properties? >> > >> > Best regards, >> > Thomas >> > >> > >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen >> > wrote: >> >> >> >> Both iso-8859-1 and utf-8 message bundles should be able to co-exist. >> >> >> >> We can allow specifying the encoding in a comment on the first line >> >> like >> >> this: >> >> >> >> # encoding=utf-8 >> >> key=value >> >> >> >> # encoding=iso-8859-1 >> >> key=value >> >> >> >> If the first line in the file doesn't contain the comment with the >> >> encoding then we should default to iso-8859-1 for backwards >> >> compatibility >> >> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >> >>> >> >>> Thanks for your comment. >> >>> >> >>> > If we want to change to utf-8 we'd still need to support iso.. for >> >>> > backwards compatibility. >> >>> >> >>> If we change to UTF-8, we can still read unicode codepoint like >> >>> '\u00e8'. >> >>> There is an incompatibility when non-ascii characters are used in >> >>> message properties. >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer codepage >> >>> layout: https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >> >>> >> >>> I think the non-ascii characters might be used in French messages like >> >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >> >>> To support this, I think we can add a property like "messageEncoding" >> >>> in keycloak-server.json as below. Is it a good idea? >> >>> >> >>> "theme": { >> >>> "staticMaxAge": 2592000, >> >>> "cacheTemplates": true, >> >>> "cacheThemes": true, >> >>> "messageEncoding": "ISO-8859-1", >> >>> "folder": { >> >>> "dir": "${jboss.home.dir}/themes" >> >>> } >> >>> }, >> >>> >> >>> Regards, >> >>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >> >>> >> >>> wrote: >> >>> > We have in the past discussed this and decided to stick with >> >>> > ISO-8859-1. >> >>> > That was probably not the best idea though. If we want to change to >> >>> > utf-8 >> >>> > we'd still need to support iso.. for backwards compatibility. >> >>> > >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira wrote: >> >>> >> >> >>> >> It makes sense, maybe file a Jira associated with: >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >> >>> >> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >> >>> >> > Hello all, >> >>> >> > >> >>> >> > I am trying to translate all base theme messages to my country >> >>> >> > language, Japanese. And I'd like to contribute them. Before that >> >>> >> > work, >> >>> >> > I'd like to propose about the files encoding. >> >>> >> > >> >>> >> > Currently, the message files (*.properties) are loaded with >> >>> >> > ISO-8859-1 >> >>> >> > encoding. Therefore, it is necessary to convert the files by >> >>> >> > 'native2ascii' command beforehand. However we can directly read >> >>> >> > the >> >>> >> > property files with UTF-8 encoding in java 1.6 or later because >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was introduced >> >>> >> > as >> >>> >> > below. >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >> >>> >> > >> >>> >> > So, my proposal is supporting the message files with UTF-8 >> >>> >> > encoding. >> >>> >> > I >> >>> >> > believe that it's very developers/customers friendly. In >> >>> >> > addition, >> >>> >> > we >> >>> >> > can easily review the translated messages on the github pull >> >>> >> > request >> >>> >> > view and so on. What do you think? >> >>> >> > >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull request. >> >>> >> > >> >>> >> > Regards, >> >>> >> > >> >>> >> > -- >> >>> >> > Hiroyuki Wada, >> >>> >> > Developer, >> >>> >> > Nomura Research Institute, Ltd. >> >>> >> > _______________________________________________ >> >>> >> > keycloak-dev mailing list >> >>> >> > keycloak-dev at lists.jboss.org >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> >> >> >>> >> -- >> >>> >> >> >>> >> abstractj >> >>> >> PGP: 0x84DC9914 >> >>> >> _______________________________________________ >> >>> >> 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 >> > >> > >> > > > > > From sthorger at redhat.com Wed Jul 6 06:36:21 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 6 Jul 2016 12:36:21 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Let's go for it. Please create a JIRA and send PR. Please just use "# encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter is just weird if you ask me. Thomas: It's optional, defaults to iso-8859-1 and the header will clearly state that a file uses a different encoding, so I disagree that there will be any confusion. On 6 July 2016 at 12:30, Hiroyuki Wada wrote: > On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme > wrote: > > From the javadoc of java.util.ResourceBundle the encoding for > .properties is > > still expected to be ISO-8859-1: > > > >> Constructing a PropertyResourceBundle instance from an InputStream > >> requires that the input stream be encoded in ISO-8859-1. In that case, > >> characters that cannot be represented in ISO-8859-1 encoding must be > >> represented by Unicode Escapes as defined in section 3.3 of The Java? > >> Language Specification whereas the other constructor which takes a > Reader > >> does not have that limitation. > > It's a case of using constructor which takes an InputStream. > It says we can use any encoding when we use the other constructor > which takes a Reader. > > I understand your concern. So what do you think supporting utf-8 with > a header like Stian suggested? > I think it can avoid confusion because the encoding is noted in the > file itself... > > Regards, > > > > https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html > > > > I understand that Spring allows one to read .properties using any > encoding, > > but you need to specify the encoding in Spring configuration external to > the > > .properties file. > > > > In my opinion it would cause unnecessary confusion amongst developers to > use > > any other encoding than the one defined by the official documentation for > > Properties. > > > > Best regards, > > Thomas > > > > > > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada > wrote: > >> > >> I think it was true before Java 1.6 because Java standard library > >> (java.util.ResourceBundle or java.util.Properties) only supported > >> ISO-8859-1 encoding file. > >> But they support any encoding after Java 1.6. There are some > >> frameworks which can read .properties with any encoding. For example, > >> Spring Framework can read .properties with any encoding. I think it's > >> very useful to read UTF-8 directly for multibyte language country. > >> > >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme > >> wrote: > >> > Please correct me if I am wrong, but I have been under the impression > >> > that > >> > Java .properties files should always use encoding ISO-8859-1. > Characters > >> > not > >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make things > >> > confusing to developers if another encoding is used here instead? > >> > > >> > > >> > > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- > >> > > >> > > https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- > >> > > >> > If alternate encodings are desired how about supporting the XML format > >> > of > >> > Properties? > >> > > >> > Best regards, > >> > Thomas > >> > > >> > > >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen > > >> > wrote: > >> >> > >> >> Both iso-8859-1 and utf-8 message bundles should be able to co-exist. > >> >> > >> >> We can allow specifying the encoding in a comment on the first line > >> >> like > >> >> this: > >> >> > >> >> # encoding=utf-8 > >> >> key=value > >> >> > >> >> # encoding=iso-8859-1 > >> >> key=value > >> >> > >> >> If the first line in the file doesn't contain the comment with the > >> >> encoding then we should default to iso-8859-1 for backwards > >> >> compatibility > >> >> > >> >> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: > >> >>> > >> >>> Thanks for your comment. > >> >>> > >> >>> > If we want to change to utf-8 we'd still need to support iso.. for > >> >>> > backwards compatibility. > >> >>> > >> >>> If we change to UTF-8, we can still read unicode codepoint like > >> >>> '\u00e8'. > >> >>> There is an incompatibility when non-ascii characters are used in > >> >>> message properties. > >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer > codepage > >> >>> layout: > https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) > >> >>> > >> >>> I think the non-ascii characters might be used in French messages > like > >> >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. > >> >>> To support this, I think we can add a property like > "messageEncoding" > >> >>> in keycloak-server.json as below. Is it a good idea? > >> >>> > >> >>> "theme": { > >> >>> "staticMaxAge": 2592000, > >> >>> "cacheTemplates": true, > >> >>> "cacheThemes": true, > >> >>> "messageEncoding": "ISO-8859-1", > >> >>> "folder": { > >> >>> "dir": "${jboss.home.dir}/themes" > >> >>> } > >> >>> }, > >> >>> > >> >>> Regards, > >> >>> > >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen > >> >>> > >> >>> wrote: > >> >>> > We have in the past discussed this and decided to stick with > >> >>> > ISO-8859-1. > >> >>> > That was probably not the best idea though. If we want to change > to > >> >>> > utf-8 > >> >>> > we'd still need to support iso.. for backwards compatibility. > >> >>> > > >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira > wrote: > >> >>> >> > >> >>> >> It makes sense, maybe file a Jira associated with: > >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? > >> >>> >> > >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: > >> >>> >> > Hello all, > >> >>> >> > > >> >>> >> > I am trying to translate all base theme messages to my country > >> >>> >> > language, Japanese. And I'd like to contribute them. Before > that > >> >>> >> > work, > >> >>> >> > I'd like to propose about the files encoding. > >> >>> >> > > >> >>> >> > Currently, the message files (*.properties) are loaded with > >> >>> >> > ISO-8859-1 > >> >>> >> > encoding. Therefore, it is necessary to convert the files by > >> >>> >> > 'native2ascii' command beforehand. However we can directly read > >> >>> >> > the > >> >>> >> > property files with UTF-8 encoding in java 1.6 or later because > >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was > introduced > >> >>> >> > as > >> >>> >> > below. > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) > >> >>> >> > > >> >>> >> > So, my proposal is supporting the message files with UTF-8 > >> >>> >> > encoding. > >> >>> >> > I > >> >>> >> > believe that it's very developers/customers friendly. In > >> >>> >> > addition, > >> >>> >> > we > >> >>> >> > can easily review the translated messages on the github pull > >> >>> >> > request > >> >>> >> > view and so on. What do you think? > >> >>> >> > > >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull request. > >> >>> >> > > >> >>> >> > Regards, > >> >>> >> > > >> >>> >> > -- > >> >>> >> > Hiroyuki Wada, > >> >>> >> > Developer, > >> >>> >> > Nomura Research Institute, Ltd. > >> >>> >> > _______________________________________________ > >> >>> >> > keycloak-dev mailing list > >> >>> >> > keycloak-dev at lists.jboss.org > >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> >>> >> > >> >>> >> -- > >> >>> >> > >> >>> >> abstractj > >> >>> >> PGP: 0x84DC9914 > >> >>> >> _______________________________________________ > >> >>> >> 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 > >> > > >> > > >> > > > > > > > > > > > _______________________________________________ > 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/20160706/534a52c4/attachment-0001.html From thomas.raehalme at aitiofinland.com Wed Jul 6 07:05:21 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 6 Jul 2016 14:05:21 +0300 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: I guess by using the header there's less chance for confusion regarding the encoding. The syntax Stian suggested for the header sounds good to me! Best regards, Thomas On Wed, Jul 6, 2016 at 1:36 PM, Stian Thorgersen wrote: > Let's go for it. Please create a JIRA and send PR. Please just use "# > encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter is just > weird if you ask me. > > Thomas: It's optional, defaults to iso-8859-1 and the header will clearly > state that a file uses a different encoding, so I disagree that there will > be any confusion. > > On 6 July 2016 at 12:30, Hiroyuki Wada wrote: > >> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >> wrote: >> > From the javadoc of java.util.ResourceBundle the encoding for >> .properties is >> > still expected to be ISO-8859-1: >> > >> >> Constructing a PropertyResourceBundle instance from an InputStream >> >> requires that the input stream be encoded in ISO-8859-1. In that case, >> >> characters that cannot be represented in ISO-8859-1 encoding must be >> >> represented by Unicode Escapes as defined in section 3.3 of The Java? >> >> Language Specification whereas the other constructor which takes a >> Reader >> >> does not have that limitation. >> >> It's a case of using constructor which takes an InputStream. >> It says we can use any encoding when we use the other constructor >> which takes a Reader. >> >> I understand your concern. So what do you think supporting utf-8 with >> a header like Stian suggested? >> I think it can avoid confusion because the encoding is noted in the >> file itself... >> >> Regards, >> >> > >> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >> > >> > I understand that Spring allows one to read .properties using any >> encoding, >> > but you need to specify the encoding in Spring configuration external >> to the >> > .properties file. >> > >> > In my opinion it would cause unnecessary confusion amongst developers >> to use >> > any other encoding than the one defined by the official documentation >> for >> > Properties. >> > >> > Best regards, >> > Thomas >> > >> > >> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada >> wrote: >> >> >> >> I think it was true before Java 1.6 because Java standard library >> >> (java.util.ResourceBundle or java.util.Properties) only supported >> >> ISO-8859-1 encoding file. >> >> But they support any encoding after Java 1.6. There are some >> >> frameworks which can read .properties with any encoding. For example, >> >> Spring Framework can read .properties with any encoding. I think it's >> >> very useful to read UTF-8 directly for multibyte language country. >> >> >> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >> >> wrote: >> >> > Please correct me if I am wrong, but I have been under the impression >> >> > that >> >> > Java .properties files should always use encoding ISO-8859-1. >> Characters >> >> > not >> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make things >> >> > confusing to developers if another encoding is used here instead? >> >> > >> >> > >> >> > >> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >> >> > >> >> > >> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >> >> > >> >> > If alternate encodings are desired how about supporting the XML >> format >> >> > of >> >> > Properties? >> >> > >> >> > Best regards, >> >> > Thomas >> >> > >> >> > >> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >> sthorger at redhat.com> >> >> > wrote: >> >> >> >> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >> co-exist. >> >> >> >> >> >> We can allow specifying the encoding in a comment on the first line >> >> >> like >> >> >> this: >> >> >> >> >> >> # encoding=utf-8 >> >> >> key=value >> >> >> >> >> >> # encoding=iso-8859-1 >> >> >> key=value >> >> >> >> >> >> If the first line in the file doesn't contain the comment with the >> >> >> encoding then we should default to iso-8859-1 for backwards >> >> >> compatibility >> >> >> >> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >> >> >>> >> >> >>> Thanks for your comment. >> >> >>> >> >> >>> > If we want to change to utf-8 we'd still need to support iso.. >> for >> >> >>> > backwards compatibility. >> >> >>> >> >> >>> If we change to UTF-8, we can still read unicode codepoint like >> >> >>> '\u00e8'. >> >> >>> There is an incompatibility when non-ascii characters are used in >> >> >>> message properties. >> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer >> codepage >> >> >>> layout: >> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >> >> >>> >> >> >>> I think the non-ascii characters might be used in French messages >> like >> >> >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >> >> >>> To support this, I think we can add a property like >> "messageEncoding" >> >> >>> in keycloak-server.json as below. Is it a good idea? >> >> >>> >> >> >>> "theme": { >> >> >>> "staticMaxAge": 2592000, >> >> >>> "cacheTemplates": true, >> >> >>> "cacheThemes": true, >> >> >>> "messageEncoding": "ISO-8859-1", >> >> >>> "folder": { >> >> >>> "dir": "${jboss.home.dir}/themes" >> >> >>> } >> >> >>> }, >> >> >>> >> >> >>> Regards, >> >> >>> >> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >> >> >>> >> >> >>> wrote: >> >> >>> > We have in the past discussed this and decided to stick with >> >> >>> > ISO-8859-1. >> >> >>> > That was probably not the best idea though. If we want to change >> to >> >> >>> > utf-8 >> >> >>> > we'd still need to support iso.. for backwards compatibility. >> >> >>> > >> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira >> wrote: >> >> >>> >> >> >> >>> >> It makes sense, maybe file a Jira associated with: >> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >> >> >>> >> >> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >> >> >>> >> > Hello all, >> >> >>> >> > >> >> >>> >> > I am trying to translate all base theme messages to my country >> >> >>> >> > language, Japanese. And I'd like to contribute them. Before >> that >> >> >>> >> > work, >> >> >>> >> > I'd like to propose about the files encoding. >> >> >>> >> > >> >> >>> >> > Currently, the message files (*.properties) are loaded with >> >> >>> >> > ISO-8859-1 >> >> >>> >> > encoding. Therefore, it is necessary to convert the files by >> >> >>> >> > 'native2ascii' command beforehand. However we can directly >> read >> >> >>> >> > the >> >> >>> >> > property files with UTF-8 encoding in java 1.6 or later >> because >> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >> introduced >> >> >>> >> > as >> >> >>> >> > below. >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >> >> >>> >> > >> >> >>> >> > So, my proposal is supporting the message files with UTF-8 >> >> >>> >> > encoding. >> >> >>> >> > I >> >> >>> >> > believe that it's very developers/customers friendly. In >> >> >>> >> > addition, >> >> >>> >> > we >> >> >>> >> > can easily review the translated messages on the github pull >> >> >>> >> > request >> >> >>> >> > view and so on. What do you think? >> >> >>> >> > >> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >> request. >> >> >>> >> > >> >> >>> >> > Regards, >> >> >>> >> > >> >> >>> >> > -- >> >> >>> >> > Hiroyuki Wada, >> >> >>> >> > Developer, >> >> >>> >> > Nomura Research Institute, Ltd. >> >> >>> >> > _______________________________________________ >> >> >>> >> > keycloak-dev mailing list >> >> >>> >> > keycloak-dev at lists.jboss.org >> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >>> >> >> >> >>> >> -- >> >> >>> >> >> >> >>> >> abstractj >> >> >>> >> PGP: 0x84DC9914 >> >> >>> >> _______________________________________________ >> >> >>> >> 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 >> >> > >> >> > >> >> > >> > >> > >> > >> > >> >> _______________________________________________ >> 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/20160706/ebc6c289/attachment.html From jdennis at redhat.com Wed Jul 6 08:28:33 2016 From: jdennis at redhat.com (John Dennis) Date: Wed, 6 Jul 2016 08:28:33 -0400 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: On 07/06/2016 03:36 AM, Stian Thorgersen wrote: > > > On 6 July 2016 at 09:07, Thomas Raehalme > > wrote: > > I didn't say using ISO-8859-1 with .properties was elegant, just the > way it is :-) > > > The fact that it's the default doesn't mean it has to be the only way ;) +1 for UTF-8 Take it from someone who has done more than his fair share of solving internationalization and character encoding issues that UTF-8 is the current defacto standard today across a wide range of technologies. It's almost universally agreed that specifying ISO-8859-1 as a default was a regrettable mistake from an earlier era before internationalization matured. There is an old proverb "no matter how far down the wrong road you've traveled it's never too late to turn back", that could be the motto for ISO-8859-1 :-) -- John From thomas.raehalme at aitiofinland.com Wed Jul 6 09:05:28 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 6 Jul 2016 16:05:28 +0300 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: On Wed, Jul 6, 2016 at 3:28 PM, John Dennis wrote: > +1 for UTF-8 > > Take it from someone who has done more than his fair share of solving > internationalization and character encoding issues that UTF-8 is the > current defacto standard today across a wide range of technologies. It's > almost universally agreed that specifying ISO-8859-1 as a default was a > regrettable mistake from an earlier era before internationalization > matured. There is an old proverb "no matter how far down the wrong road > you've traveled it's never too late to turn back", that could be the motto > for ISO-8859-1 :-) > I share your pain, but most of my problems have been due to applications not following standards or by expecting the system encoding to be something it's not and not allowing you to specify the correct encoding. I also agree with you that UTF-8 is the encoding to use, UNLESS it's common practice/a de-facto standard to be using something else which it is for .properties files. If everybody presumes they are ISO-8859-1 then we should not confuse people by defaulting to something else. That being said I think using a header to specify the non-default encoding, eg. UTF-8 is a good compromise. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160706/4ae692c4/attachment.html From singhrasster at gmail.com Wed Jul 6 22:03:54 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Wed, 6 Jul 2016 21:03:54 -0500 Subject: [keycloak-dev] How to setup a maven project generating jar containing authentication providers in a debug mode in eclipse In-Reply-To: References: Message-ID: Does anyone have a clue on this issue I am having? On Sat, Jul 2, 2016 at 7:13 PM, Rashmi Singh wrote: > Thanks for your reply Francis. I still have one problem: > > When I run this: > $ docker run --name keycloak1 -p 8080:8080 -p 8787:8787 jboss/keycloak > > I can access the keycloak app console on http://192.168.99.100:8080/auth/ > from my browser > > But when I run it in debug mode as: > $ docker run --name keycloak1 -p 8080:8080 -p 8787:8787 jboss/keycloak > --debug > > I cannot access the keycloak console. What is wrong here, any idea? > > On Fri, Jul 1, 2016 at 12:48 AM, Francis Pouatcha < > francis.pouatcha at adorsys.com> wrote: > >> Rashmi, >> >> follow these instructions to have keycloack debug accessible from eclipse: >> >> 1- Simple web application >> User a simple HelloServlet to try out the debugging process before >> applying you experience to wildfly. >> >> 1- Wildfly and eclipse >> Like Thomas mentioned, Make sure you active the debug property while >> starting wildfly. This is independent of keycloak, as keycloak is just >> another web application running on wildfly. So make sure you have a simple >> webapp running in wildfly standalone so you can get used to the debugging >> process. >> >> 2- Wildfly in a docker container >> Take your simple web application and wildfly into a docker container and >> try following: >> a) Make sure you start wildfly in the container in debug mode. Not matter >> how you manage the docker containers in your development environment, you >> will have to expose their ports so you can reach the container from and >> outside the docker host. "Exposing the port means mapping the defined >> wildfly ports to some other ports on the docker host. If you are using >> docker-composer you have to try something like: ports:\ - "8080:8080"\ >> - "8787:8787". In this case see the docker-compose reference for details. >> >> 3- Accessing the docker container >> Once you wildfly docker container is startet in debug mode, make sure you >> can access you HelloServlet from a web browser on the same machine on >> which you have your eclipse installed. If this works, use the same hostname >> or ip to replace "localhost" in you eclipse debugging config. Generally >> this will default to: 192.168.99.100:8787. >> >> You did it right, you will be able to stop on the breakpoint inside your >> HelloServlet. >> >> 4- Keycloak >> Repeat the same procedure with your custom authenticator. Do not forget >> to download the keycloak sources and include them in your the source path >> so you can navigate and set break points. >> >> >> Best regards >> Mit freundlichen Gr??en >> Cordialement >> >> Francis Pouatcha >> Founder and Technical Lead Group Adorsys >> >> LinkedIn: http://www.linkedin.com/pub/francis-pouatcha/8/35a/542 >> adorsys GmbH & Co. KG, Germany: >> http://www.youtube.com/watch?v=rVRkFGUNexo&authuser=0 >> Adorsys S.A., Cameroon: "African Software Competence Center" >> Open https://github.com/adorsys >> >> Cell USA: +1 770 329 7026 >> Cell Germany: +49 172 18 16 074 >> Cell Cameroon: +237 51 74 71 99 >> >> >> On Fri, Jul 1, 2016 at 2:39 AM, Rashmi Singh >> wrote: >> >>> Thanks Thomas for your reply. I have a few questions on your response. I >>> am still very new to docker, so please bear with me. >>> when you say I can set env variables in docker container, would this be >>> sufficient? >>> >>> First connect to the docker container as: >>> >>> docker exec -i -t keycloak bash >>> Then, once I am in the container, I run the following to set env >>> variables? >>> >>> set DEBUG_MODE=true >>> set DEBUG_PORT=8787 >>> exit >>> Then, restart the container as: >>> docker restart keycloak (keycloak is the name of my container) >>> Also, how can I make sure that the env variable got correctly set in the >>> docker container? From inside the container, if I run the command "env", >>> should it list these new env variables if they are added successfully? >>> >>> Then, when you say "......default on port 8787 which you need to expose >>> on your docker container or use the container interface...", what exactly >>> do you mean? Do you mean some sort of port forwarding? Could you tell me w >>> tohat exactly I need to do with my existing container named as "keycloak" >>> >>> Then, on eclipse, where you mentioned the settings for the Debug >>> configurations, what should be the hostname there? would it be localhost? >>> or the default machine IP of docker which is 192.168.99.100? Or it should >>> be something else? >>> >>> >>> >>> On Thu, Jun 30, 2016 at 6:29 PM, Thomas Darimont < >>> thomas.darimont at googlemail.com> wrote: >>> >>>> Hello, >>>> >>>> you could add -debug flag to the standalone.sh command-line or define >>>> the following env variables in your docker container: >>>> set DEBUG_MODE=true >>>> set DEBUG_PORT=8787 >>>> >>>> this will start keycloak with remote debugging enabled by default on >>>> port 8787 which you need to expose on your docker container or use the >>>> container interface... >>>> >>>> you can then connect to the keycloak instance inside the docker >>>> container via the remote debugger from your IDE. >>>> For eclipse just go to "Debug configurations..." -> Remote Java >>>> Application -> select your project with the custom authenticator -> adjust >>>> hostname and port and click "debug". >>>> >>>> Cheers, >>>> Thomas >>>> >>>> 2016-07-01 0:26 GMT+02:00 Rashmi Singh : >>>> >>>>> We have a Maven project setup on Eclipse that uses some keycloak >>>>> features and we generate a jar that contains our AuthenticationProvider >>>>> classes etc. >>>>> We use docker for the deployment. We basically run a jboss/keycloak >>>>> image there >>>>> We have a shell script that has a bunch of commands to copy our >>>>> project jars from local to the keycloak image on docker container like: >>>>> >>>>> docker cp /customauthenticator-1.0.0-SNAPSHOT.jar >>>>> keycloak:/home/modules/xxx.yyy.zz.keycloak.customizations >>>>> .... >>>>> docker restart keycloak >>>>> >>>>> Running this shell script deploys everything on keycloak on docker. >>>>> And so far we are just putting logs throughout our code to debug >>>>> issues. >>>>> We want to be able to setup a debugging environment on our eclipse. I >>>>> am not sure how to achieve this when we use keycloak. Because, here we >>>>> basically build our modules or authenticator jars etc and copy them to >>>>> keycloak directories. So, it's not a standalone project war file that we >>>>> are directly deploying to app server as such. So, then how do we put our >>>>> maven project (creating jars etc) in a debug mode in eclipse? Is it >>>>> possible? How? >>>>> >>>>> _______________________________________________ >>>>> 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/20160706/69b24f69/attachment.html From vramik at redhat.com Thu Jul 7 03:02:53 2016 From: vramik at redhat.com (Vlasta Ramik) Date: Thu, 7 Jul 2016 09:02:53 +0200 Subject: [keycloak-dev] Tomcat 8 Arquillian Tests In-Reply-To: <1494239438.5788955.1467645005286.JavaMail.zimbra@redhat.com> References: <1494239438.5788955.1467645005286.JavaMail.zimbra@redhat.com> Message-ID: <577DFE9D.8090304@redhat.com> Hi Pedro, you need to build distribution first, if you already didn't so. mvn clean install -Pdistribution -DskipTests cd testsuite/integration-arquillian mvn clean install -Pauth-server-wildfly,app-server-tomcat8 -Dtest=Tomcat8DemoExampleAdapterTest or mvn clean install -Pdistribution,auth-server-wildfly,app-server-tomcat8 -Dtest=Tomcat8DemoExampleAdapterTest But currently tomcat tests fails because testsuite expects that server runs on port 8280, not tomcat default 8080. I'm working on it to fix this. Vlasta On 07/04/2016 05:10 PM, Pedro Igor Silva wrote: > Hi, > > Is that command correct in order to get adapter tests running against a Tomcat 8 app server ? > > mvn -Pauth-server-wildfly -Papp-server-tomcat8 -Pexamples clean install -Dtest=Tomcat8DemoExampleAdapterTest > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Thu Jul 7 03:45:36 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 7 Jul 2016 09:45:36 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> <5776C857.2070703@redhat.com> Message-ID: <577E08A0.4010409@redhat.com> On 04/07/16 09:47, Stian Thorgersen wrote: > ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite > sure how it would look like to an end-user. > > * Are these managed on a separate screen or on the protocol mappers > screen? I am thinking about the protocolMappers screen. Just add another "type" of protocolMapper. This means that we don't need to add another concept/modelType just for scope parameter, but still we can easily filter/view the available mappers of type 'scope aggregator' (on the screen with list of all protocolMappers). > * How do users define and view scopes, including viewing what > claims/mappers/roles are associated with a scope? > * How does a user add/remove claims, protocol mappers and roles to > a ScopeAggregatorProtocolMapper? I am thinking that for roles, you will select the roles in same way, like it's in current "Scopes" tab of client (or "role mappings" tab of user). Probably very similar UI can be used for selecting "children" mappers of current protocolMapper though? Something like "Available mappers" and "Assigned mappers" and buttons like "Add selected" and "Remove selected". Also similarly like for roles, you can view in "Effective mappers" the list of all effective mappers in case that you have more composed aggregated scopeAggregatorMappers. For example, if you have mapper for scope parameter "full-profile", which will have children mappers, that will point to other scope aggregated mappers : "profile" , "email" and "phone". Hence in "Effective mappers" for "full-profile" you will see all the descendants, not just the direct children. So you will see also all the simple attribute mappers like "firstName", "lastName", "birthday", "phone number", ... > * Do we provide one or more built-in ScopeAggregatorProtocolMapper > that are configurable? I assume so and that users don't have to > programatically define scopes. Yes. I think that we should provide those built-in, which are specified by OIDC specification. Which is "profile" , "email" , "phone" , "address". And we will need to define mappers for all their simple attributes ( "birthday", "gender" , ...) . Those simple mappers like "birthday" won't be root mappers by default, so they won't be applied unless the scope parameter is used (for their parent scopeAggregatorMapper). For backwards compatibility, we will still use the same 'simple' mappers like now ( username, email, full name, family name, given name) and they will be added to token by default. The scopeAggregator mappers (and their corresponding children) will be applied just if the scope parameter with corresponding value will be used. > * Can a scope resolve to multiple ScopeAggregatorProtocolMapper? Yes (see above) Marek > > On 1 July 2016 at 21:45, Marek Posolda > wrote: > > Ok, I wasn't also 100% keen about using role. > > Thinking also about what Pedro mentioned before about protocol > mappers. So I wonder that instead of introduce new "scope" > concept, we just reuse protocolMappers SPI and have special impl > of protocolMapper, which is able to deal with scope parameter and > aggregate other "children" protocolMappers and roles? > > Something like this: > - There will be new ProtocolMapper implementation like > ScopeAggregatorProtocolMapper. You will define value of scope > parameter (eg. "photo" ) in the configuration of this > protocolMapper. Mapper will be ignored if scope parameter value > with this name was not used. > > - You will be able to define "children" protocolMappers and > "children" roles in ScopeAggregatorProtocolMapper. > > - For each client (and clientTemplate), we will have many defined > protocolMappers, but just some subset of them are "root" mappers, > which are applied by default. The rest of mappers will be used > just as "children" of root mappers. So in client model, we might have: > client.getDefinedProtocolMappers() // all defined > client.getProtocolMappers() // just subset of defined (defacto > root mappers) > > - For example: client will have defined protocolMappers: > firstName, lastName, birthday, profile, email. Just "profile" and > "email" will be root mappers. And "profile" is > ScopeAggregatorMapper for scope value "profile" and it's children > mappers are : firstName, lastName, birthday. > > So then: > -- user will send "scope=profile" . Then defacto all of > "firstName", "lastName", "birthday", "email" claims will be > included in token. On consent screen will be just "Profile" and > "Email" > -- user won't send "scope=profile" . Then defacto just "email" > claim will be included (So for this example, email is always > included even if not specified by scope parameter). > > - With this concept, we are able to aggregate many various claims > into single value of "scope" and on the consent screen have just > the roots. This would fit well for the default scope values > mentioned by OIDC specs. We are also able to define mappers > (claims), which will be always available even if not specified by > scope parameter. > > - For the roles, I am not 100% sure whether to include them into > the concept or not? However it seems to me that rather yes. The > particular role will be applied into token just if all of those 3 > conditions are met: > 1) user is member of the role > 2) client has scope for the role (so current "scope" tab in > clients will remain as is) > 3) if role has scopePAramRequired=true, then it must be included > in some mapper (in other words, those roles are not included > directly in clientSession.getRoles , but it's the responsibility > of ScopeAggregatorProtocolMapper to add them into token if > conditions 1+2 are met). > > So again, user won't see all children roles on consent screen. > Just the parent protocolMapper. > > This will work fine with "scope=offline_access" . There will be > protocolMapper for "offline_access" parameter, which will > aggregate just one children role (the current realm role > "offline_access"). The offline token will be issued just if > accessToken will have "offline_access" permission. So if some > client, doesn't need offline tokens, it can just remove > "offline_access" protocolMapper. Also if some user shouldn't be > allowed to request offline tokens, admin can remove him from the > "offline_access" role. > > - If some scope parameter is applicable for more clients, it can > be defined on clientTemplate. > > > PS: I will be on holidays and back on next Thursday 7th July. So > sorry if I won't reply immediately to next mails. > > Mare > > > > On 01/07/16 14:57, Pedro Igor Silva wrote: > > Reading all of this makes me think it would be cleaner to > introduce a > separate scope concept ;) > > A user doesn't have a scope - a user has roles and > attributes. Re-using roles > concept for the scope just makes it feel awkward and > retrofitted. > > +10000 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160707/aa7217ce/attachment.html From sthorger at redhat.com Thu Jul 7 06:07:58 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 7 Jul 2016 12:07:58 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <577E08A0.4010409@redhat.com> References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> <5776C857.2070703@redhat.com> <577E08A0.4010409@redhat.com> Message-ID: On 7 July 2016 at 09:45, Marek Posolda wrote: > On 04/07/16 09:47, Stian Thorgersen wrote: > > ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure > how it would look like to an end-user. > > * Are these managed on a separate screen or on the protocol mappers > screen? > > I am thinking about the protocolMappers screen. Just add another "type" of > protocolMapper. This means that we don't need to add another > concept/modelType just for scope parameter, but still we can easily > filter/view the available mappers of type 'scope aggregator' (on the screen > with list of all protocolMappers). > Not quite sure I see why it should be on the protocol mappers screen. As it's a separate type of mapper as well the UI to define them would be different I'm not sure I see why it can't be a separate screen. I think it would fit better on the scope tab. It could have two tabs "Default scope" and "Scopes" or something like that. > > * How do users define and view scopes, including viewing what > claims/mappers/roles are associated with a scope? > * How does a user add/remove claims, protocol mappers and roles to > a ScopeAggregatorProtocolMapper? > > I am thinking that for roles, you will select the roles in same way, like > it's in current "Scopes" tab of client (or "role mappings" tab of user). > Probably very similar UI can be used for selecting "children" mappers of > current protocolMapper though? Something like "Available mappers" and > "Assigned mappers" and buttons like "Add selected" and "Remove selected". > Also similarly like for roles, you can view in "Effective mappers" the list > of all effective mappers in case that you have more composed aggregated > scopeAggregatorMappers. > > For example, if you have mapper for scope parameter "full-profile", which > will have children mappers, that will point to other scope aggregated > mappers : "profile" , "email" and "phone". Hence in "Effective mappers" for > "full-profile" you will see all the descendants, not just the direct > children. So you will see also all the simple attribute mappers like > "firstName", "lastName", "birthday", "phone number", ... > Sounds good > > * Do we provide one or more built-in ScopeAggregatorProtocolMapper that > are configurable? I assume so and that users don't have to programatically > define scopes. > > Yes. I think that we should provide those built-in, which are specified by > OIDC specification. Which is "profile" , "email" , "phone" , "address". And > we will need to define mappers for all their simple attributes ( > "birthday", "gender" , ...) . Those simple mappers like "birthday" won't be > root mappers by default, so they won't be applied unless the scope > parameter is used (for their parent scopeAggregatorMapper). > > For backwards compatibility, we will still use the same 'simple' mappers > like now ( username, email, full name, family name, given name) and they > will be added to token by default. The scopeAggregator mappers (and their > corresponding children) will be applied just if the scope parameter with > corresponding value will be used. > SAML doesn't have this concept does it? If so it probably doesn't even make sense to show scope mappers for SAML clients. > > > * Can a scope resolve to multiple ScopeAggregatorProtocolMapper? > > Yes (see above) > > Marek > > > On 1 July 2016 at 21:45, Marek Posolda wrote: > >> Ok, I wasn't also 100% keen about using role. >> >> Thinking also about what Pedro mentioned before about protocol mappers. >> So I wonder that instead of introduce new "scope" concept, we just reuse >> protocolMappers SPI and have special impl of protocolMapper, which is able >> to deal with scope parameter and aggregate other "children" protocolMappers >> and roles? >> >> Something like this: >> - There will be new ProtocolMapper implementation like >> ScopeAggregatorProtocolMapper. You will define value of scope parameter >> (eg. "photo" ) in the configuration of this protocolMapper. Mapper will be >> ignored if scope parameter value with this name was not used. >> >> - You will be able to define "children" protocolMappers and "children" >> roles in ScopeAggregatorProtocolMapper. >> >> - For each client (and clientTemplate), we will have many defined >> protocolMappers, but just some subset of them are "root" mappers, which are >> applied by default. The rest of mappers will be used just as "children" of >> root mappers. So in client model, we might have: >> client.getDefinedProtocolMappers() // all defined >> client.getProtocolMappers() // just subset of defined (defacto root >> mappers) >> >> - For example: client will have defined protocolMappers: firstName, >> lastName, birthday, profile, email. Just "profile" and "email" will be root >> mappers. And "profile" is ScopeAggregatorMapper for scope value "profile" >> and it's children mappers are : firstName, lastName, birthday. >> >> So then: >> -- user will send "scope=profile" . Then defacto all of "firstName", >> "lastName", "birthday", "email" claims will be included in token. On >> consent screen will be just "Profile" and "Email" >> -- user won't send "scope=profile" . Then defacto just "email" claim will >> be included (So for this example, email is always included even if not >> specified by scope parameter). >> >> - With this concept, we are able to aggregate many various claims into >> single value of "scope" and on the consent screen have just the roots. This >> would fit well for the default scope values mentioned by OIDC specs. We are >> also able to define mappers (claims), which will be always available even >> if not specified by scope parameter. >> >> - For the roles, I am not 100% sure whether to include them into the >> concept or not? However it seems to me that rather yes. The particular role >> will be applied into token just if all of those 3 conditions are met: >> 1) user is member of the role >> 2) client has scope for the role (so current "scope" tab in clients will >> remain as is) >> 3) if role has scopePAramRequired=true, then it must be included in some >> mapper (in other words, those roles are not included directly in >> clientSession.getRoles , but it's the responsibility of >> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are >> met). >> >> So again, user won't see all children roles on consent screen. Just the >> parent protocolMapper. >> >> This will work fine with "scope=offline_access" . There will be >> protocolMapper for "offline_access" parameter, which will aggregate just >> one children role (the current realm role "offline_access"). The offline >> token will be issued just if accessToken will have "offline_access" >> permission. So if some client, doesn't need offline tokens, it can just >> remove "offline_access" protocolMapper. Also if some user shouldn't be >> allowed to request offline tokens, admin can remove him from the >> "offline_access" role. >> >> - If some scope parameter is applicable for more clients, it can be >> defined on clientTemplate. >> >> >> PS: I will be on holidays and back on next Thursday 7th July. So sorry if >> I won't reply immediately to next mails. >> >> Mare >> >> >> >> On 01/07/16 14:57, Pedro Igor Silva wrote: >> >>> Reading all of this makes me think it would be cleaner to introduce a >>>> separate scope concept ;) >>>> >>>> A user doesn't have a scope - a user has roles and attributes. Re-using >>>> roles >>>> concept for the scope just makes it feel awkward and retrofitted. >>>> >>> +10000 >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160707/858735df/attachment-0001.html From wadahiro at gmail.com Thu Jul 7 06:33:10 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Thu, 07 Jul 2016 10:33:10 +0000 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Ok. I created a JIRA issue. https://issues.jboss.org/browse/KEYCLOAK-3278 2016?7?6?(?) 19:36 Stian Thorgersen : > Let's go for it. Please create a JIRA and send PR. Please just use "# > encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter is just > weird if you ask me. > > Thomas: It's optional, defaults to iso-8859-1 and the header will clearly > state that a file uses a different encoding, so I disagree that there will > be any confusion. > > On 6 July 2016 at 12:30, Hiroyuki Wada wrote: > >> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >> wrote: >> > From the javadoc of java.util.ResourceBundle the encoding for >> .properties is >> > still expected to be ISO-8859-1: >> > >> >> Constructing a PropertyResourceBundle instance from an InputStream >> >> requires that the input stream be encoded in ISO-8859-1. In that case, >> >> characters that cannot be represented in ISO-8859-1 encoding must be >> >> represented by Unicode Escapes as defined in section 3.3 of The Java? >> >> Language Specification whereas the other constructor which takes a >> Reader >> >> does not have that limitation. >> >> It's a case of using constructor which takes an InputStream. >> It says we can use any encoding when we use the other constructor >> which takes a Reader. >> >> I understand your concern. So what do you think supporting utf-8 with >> a header like Stian suggested? >> I think it can avoid confusion because the encoding is noted in the >> file itself... >> >> Regards, >> >> > >> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >> > >> > I understand that Spring allows one to read .properties using any >> encoding, >> > but you need to specify the encoding in Spring configuration external >> to the >> > .properties file. >> > >> > In my opinion it would cause unnecessary confusion amongst developers >> to use >> > any other encoding than the one defined by the official documentation >> for >> > Properties. >> > >> > Best regards, >> > Thomas >> > >> > >> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada >> wrote: >> >> >> >> I think it was true before Java 1.6 because Java standard library >> >> (java.util.ResourceBundle or java.util.Properties) only supported >> >> ISO-8859-1 encoding file. >> >> But they support any encoding after Java 1.6. There are some >> >> frameworks which can read .properties with any encoding. For example, >> >> Spring Framework can read .properties with any encoding. I think it's >> >> very useful to read UTF-8 directly for multibyte language country. >> >> >> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >> >> wrote: >> >> > Please correct me if I am wrong, but I have been under the impression >> >> > that >> >> > Java .properties files should always use encoding ISO-8859-1. >> Characters >> >> > not >> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make things >> >> > confusing to developers if another encoding is used here instead? >> >> > >> >> > >> >> > >> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >> >> > >> >> > >> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >> >> > >> >> > If alternate encodings are desired how about supporting the XML >> format >> >> > of >> >> > Properties? >> >> > >> >> > Best regards, >> >> > Thomas >> >> > >> >> > >> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >> sthorger at redhat.com> >> >> > wrote: >> >> >> >> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >> co-exist. >> >> >> >> >> >> We can allow specifying the encoding in a comment on the first line >> >> >> like >> >> >> this: >> >> >> >> >> >> # encoding=utf-8 >> >> >> key=value >> >> >> >> >> >> # encoding=iso-8859-1 >> >> >> key=value >> >> >> >> >> >> If the first line in the file doesn't contain the comment with the >> >> >> encoding then we should default to iso-8859-1 for backwards >> >> >> compatibility >> >> >> >> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >> >> >>> >> >> >>> Thanks for your comment. >> >> >>> >> >> >>> > If we want to change to utf-8 we'd still need to support iso.. >> for >> >> >>> > backwards compatibility. >> >> >>> >> >> >>> If we change to UTF-8, we can still read unicode codepoint like >> >> >>> '\u00e8'. >> >> >>> There is an incompatibility when non-ascii characters are used in >> >> >>> message properties. >> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer >> codepage >> >> >>> layout: >> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >> >> >>> >> >> >>> I think the non-ascii characters might be used in French messages >> like >> >> >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >> >> >>> To support this, I think we can add a property like >> "messageEncoding" >> >> >>> in keycloak-server.json as below. Is it a good idea? >> >> >>> >> >> >>> "theme": { >> >> >>> "staticMaxAge": 2592000, >> >> >>> "cacheTemplates": true, >> >> >>> "cacheThemes": true, >> >> >>> "messageEncoding": "ISO-8859-1", >> >> >>> "folder": { >> >> >>> "dir": "${jboss.home.dir}/themes" >> >> >>> } >> >> >>> }, >> >> >>> >> >> >>> Regards, >> >> >>> >> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >> >> >>> >> >> >>> wrote: >> >> >>> > We have in the past discussed this and decided to stick with >> >> >>> > ISO-8859-1. >> >> >>> > That was probably not the best idea though. If we want to change >> to >> >> >>> > utf-8 >> >> >>> > we'd still need to support iso.. for backwards compatibility. >> >> >>> > >> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira >> wrote: >> >> >>> >> >> >> >>> >> It makes sense, maybe file a Jira associated with: >> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >> >> >>> >> >> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >> >> >>> >> > Hello all, >> >> >>> >> > >> >> >>> >> > I am trying to translate all base theme messages to my country >> >> >>> >> > language, Japanese. And I'd like to contribute them. Before >> that >> >> >>> >> > work, >> >> >>> >> > I'd like to propose about the files encoding. >> >> >>> >> > >> >> >>> >> > Currently, the message files (*.properties) are loaded with >> >> >>> >> > ISO-8859-1 >> >> >>> >> > encoding. Therefore, it is necessary to convert the files by >> >> >>> >> > 'native2ascii' command beforehand. However we can directly >> read >> >> >>> >> > the >> >> >>> >> > property files with UTF-8 encoding in java 1.6 or later >> because >> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >> introduced >> >> >>> >> > as >> >> >>> >> > below. >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >> >> >>> >> > >> >> >>> >> > So, my proposal is supporting the message files with UTF-8 >> >> >>> >> > encoding. >> >> >>> >> > I >> >> >>> >> > believe that it's very developers/customers friendly. In >> >> >>> >> > addition, >> >> >>> >> > we >> >> >>> >> > can easily review the translated messages on the github pull >> >> >>> >> > request >> >> >>> >> > view and so on. What do you think? >> >> >>> >> > >> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >> request. >> >> >>> >> > >> >> >>> >> > Regards, >> >> >>> >> > >> >> >>> >> > -- >> >> >>> >> > Hiroyuki Wada, >> >> >>> >> > Developer, >> >> >>> >> > Nomura Research Institute, Ltd. >> >> >>> >> > _______________________________________________ >> >> >>> >> > keycloak-dev mailing list >> >> >>> >> > keycloak-dev at lists.jboss.org >> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >>> >> >> >> >>> >> -- >> >> >>> >> >> >> >>> >> abstractj >> >> >>> >> PGP: 0x84DC9914 >> >> >>> >> _______________________________________________ >> >> >>> >> 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 >> >> > >> >> > >> >> > >> > >> > >> > >> > >> >> _______________________________________________ >> 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/20160707/475b348d/attachment.html From sthorger at redhat.com Thu Jul 7 08:20:41 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 7 Jul 2016 14:20:41 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Are you doing a PR as well? On 7 July 2016 at 12:33, Hiroyuki Wada wrote: > Ok. I created a JIRA issue. > https://issues.jboss.org/browse/KEYCLOAK-3278 > > 2016?7?6?(?) 19:36 Stian Thorgersen : > >> Let's go for it. Please create a JIRA and send PR. Please just use "# >> encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter is just >> weird if you ask me. >> >> Thomas: It's optional, defaults to iso-8859-1 and the header will clearly >> state that a file uses a different encoding, so I disagree that there will >> be any confusion. >> >> On 6 July 2016 at 12:30, Hiroyuki Wada wrote: >> >>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>> wrote: >>> > From the javadoc of java.util.ResourceBundle the encoding for >>> .properties is >>> > still expected to be ISO-8859-1: >>> > >>> >> Constructing a PropertyResourceBundle instance from an InputStream >>> >> requires that the input stream be encoded in ISO-8859-1. In that case, >>> >> characters that cannot be represented in ISO-8859-1 encoding must be >>> >> represented by Unicode Escapes as defined in section 3.3 of The Java? >>> >> Language Specification whereas the other constructor which takes a >>> Reader >>> >> does not have that limitation. >>> >>> It's a case of using constructor which takes an InputStream. >>> It says we can use any encoding when we use the other constructor >>> which takes a Reader. >>> >>> I understand your concern. So what do you think supporting utf-8 with >>> a header like Stian suggested? >>> I think it can avoid confusion because the encoding is noted in the >>> file itself... >>> >>> Regards, >>> >>> > >>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>> > >>> > I understand that Spring allows one to read .properties using any >>> encoding, >>> > but you need to specify the encoding in Spring configuration external >>> to the >>> > .properties file. >>> > >>> > In my opinion it would cause unnecessary confusion amongst developers >>> to use >>> > any other encoding than the one defined by the official documentation >>> for >>> > Properties. >>> > >>> > Best regards, >>> > Thomas >>> > >>> > >>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada >>> wrote: >>> >> >>> >> I think it was true before Java 1.6 because Java standard library >>> >> (java.util.ResourceBundle or java.util.Properties) only supported >>> >> ISO-8859-1 encoding file. >>> >> But they support any encoding after Java 1.6. There are some >>> >> frameworks which can read .properties with any encoding. For example, >>> >> Spring Framework can read .properties with any encoding. I think it's >>> >> very useful to read UTF-8 directly for multibyte language country. >>> >> >>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>> >> wrote: >>> >> > Please correct me if I am wrong, but I have been under the >>> impression >>> >> > that >>> >> > Java .properties files should always use encoding ISO-8859-1. >>> Characters >>> >> > not >>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make things >>> >> > confusing to developers if another encoding is used here instead? >>> >> > >>> >> > >>> >> > >>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>> >> > >>> >> > >>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>> >> > >>> >> > If alternate encodings are desired how about supporting the XML >>> format >>> >> > of >>> >> > Properties? >>> >> > >>> >> > Best regards, >>> >> > Thomas >>> >> > >>> >> > >>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>> sthorger at redhat.com> >>> >> > wrote: >>> >> >> >>> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >>> co-exist. >>> >> >> >>> >> >> We can allow specifying the encoding in a comment on the first line >>> >> >> like >>> >> >> this: >>> >> >> >>> >> >> # encoding=utf-8 >>> >> >> key=value >>> >> >> >>> >> >> # encoding=iso-8859-1 >>> >> >> key=value >>> >> >> >>> >> >> If the first line in the file doesn't contain the comment with the >>> >> >> encoding then we should default to iso-8859-1 for backwards >>> >> >> compatibility >>> >> >> >>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada wrote: >>> >> >>> >>> >> >>> Thanks for your comment. >>> >> >>> >>> >> >>> > If we want to change to utf-8 we'd still need to support iso.. >>> for >>> >> >>> > backwards compatibility. >>> >> >>> >>> >> >>> If we change to UTF-8, we can still read unicode codepoint like >>> >> >>> '\u00e8'. >>> >> >>> There is an incompatibility when non-ascii characters are used in >>> >> >>> message properties. >>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer >>> codepage >>> >> >>> layout: >>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>> >> >>> >>> >> >>> I think the non-ascii characters might be used in French messages >>> like >>> >> >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >>> >> >>> To support this, I think we can add a property like >>> "messageEncoding" >>> >> >>> in keycloak-server.json as below. Is it a good idea? >>> >> >>> >>> >> >>> "theme": { >>> >> >>> "staticMaxAge": 2592000, >>> >> >>> "cacheTemplates": true, >>> >> >>> "cacheThemes": true, >>> >> >>> "messageEncoding": "ISO-8859-1", >>> >> >>> "folder": { >>> >> >>> "dir": "${jboss.home.dir}/themes" >>> >> >>> } >>> >> >>> }, >>> >> >>> >>> >> >>> Regards, >>> >> >>> >>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>> >> >>> >>> >> >>> wrote: >>> >> >>> > We have in the past discussed this and decided to stick with >>> >> >>> > ISO-8859-1. >>> >> >>> > That was probably not the best idea though. If we want to >>> change to >>> >> >>> > utf-8 >>> >> >>> > we'd still need to support iso.. for backwards compatibility. >>> >> >>> > >>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira >>> wrote: >>> >> >>> >> >>> >> >>> >> It makes sense, maybe file a Jira associated with: >>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>> >> >>> >> >>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>> >> >>> >> > Hello all, >>> >> >>> >> > >>> >> >>> >> > I am trying to translate all base theme messages to my >>> country >>> >> >>> >> > language, Japanese. And I'd like to contribute them. Before >>> that >>> >> >>> >> > work, >>> >> >>> >> > I'd like to propose about the files encoding. >>> >> >>> >> > >>> >> >>> >> > Currently, the message files (*.properties) are loaded with >>> >> >>> >> > ISO-8859-1 >>> >> >>> >> > encoding. Therefore, it is necessary to convert the files by >>> >> >>> >> > 'native2ascii' command beforehand. However we can directly >>> read >>> >> >>> >> > the >>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or later >>> because >>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >>> introduced >>> >> >>> >> > as >>> >> >>> >> > below. >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> >> >>> >> > >>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>> >> >>> >> > >>> >> >>> >> > So, my proposal is supporting the message files with UTF-8 >>> >> >>> >> > encoding. >>> >> >>> >> > I >>> >> >>> >> > believe that it's very developers/customers friendly. In >>> >> >>> >> > addition, >>> >> >>> >> > we >>> >> >>> >> > can easily review the translated messages on the github pull >>> >> >>> >> > request >>> >> >>> >> > view and so on. What do you think? >>> >> >>> >> > >>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >>> request. >>> >> >>> >> > >>> >> >>> >> > Regards, >>> >> >>> >> > >>> >> >>> >> > -- >>> >> >>> >> > Hiroyuki Wada, >>> >> >>> >> > Developer, >>> >> >>> >> > Nomura Research Institute, Ltd. >>> >> >>> >> > _______________________________________________ >>> >> >>> >> > keycloak-dev mailing list >>> >> >>> >> > keycloak-dev at lists.jboss.org >>> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> >>> >> >>> >> abstractj >>> >> >>> >> PGP: 0x84DC9914 >>> >> >>> >> _______________________________________________ >>> >> >>> >> 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 >>> >> > >>> >> > >>> >> > >>> > >>> > >>> > >>> > >>> >>> _______________________________________________ >>> 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/20160707/53b8c276/attachment-0001.html From bruno at abstractj.org Thu Jul 7 08:31:40 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Jul 2016 09:31:40 -0300 Subject: [keycloak-dev] Is including adapter libs directly in WAR supported on WildFly/EAP In-Reply-To: References: Message-ID: <20160707123140.GC30105@abstractj.org> On 2016-07-01, Stian Thorgersen wrote: > Do we support (or need to support) including adapter libraries directly in > the WAR? Or should we just support using the subsystem? > > If we support including libraries directly that may not work at the moment > and would certainly require documenting and also testing, so my vote is to > only support the subsystem approach. +1 for subsystem only, less confusion > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From wadahiro at gmail.com Thu Jul 7 08:39:39 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Thu, 07 Jul 2016 12:39:39 +0000 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Yes. I will send a pull request later! 2016?7?7?(?) 21:20 Stian Thorgersen : > Are you doing a PR as well? > > On 7 July 2016 at 12:33, Hiroyuki Wada wrote: > >> Ok. I created a JIRA issue. >> https://issues.jboss.org/browse/KEYCLOAK-3278 >> >> 2016?7?6?(?) 19:36 Stian Thorgersen : >> >>> Let's go for it. Please create a JIRA and send PR. Please just use "# >>> encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter is just >>> weird if you ask me. >>> >>> Thomas: It's optional, defaults to iso-8859-1 and the header will >>> clearly state that a file uses a different encoding, so I disagree that >>> there will be any confusion. >>> >>> On 6 July 2016 at 12:30, Hiroyuki Wada wrote: >>> >>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>> wrote: >>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>> .properties is >>>> > still expected to be ISO-8859-1: >>>> > >>>> >> Constructing a PropertyResourceBundle instance from an InputStream >>>> >> requires that the input stream be encoded in ISO-8859-1. In that >>>> case, >>>> >> characters that cannot be represented in ISO-8859-1 encoding must be >>>> >> represented by Unicode Escapes as defined in section 3.3 of The Java? >>>> >> Language Specification whereas the other constructor which takes a >>>> Reader >>>> >> does not have that limitation. >>>> >>>> It's a case of using constructor which takes an InputStream. >>>> It says we can use any encoding when we use the other constructor >>>> which takes a Reader. >>>> >>>> I understand your concern. So what do you think supporting utf-8 with >>>> a header like Stian suggested? >>>> I think it can avoid confusion because the encoding is noted in the >>>> file itself... >>>> >>>> Regards, >>>> >>>> > >>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>> > >>>> > I understand that Spring allows one to read .properties using any >>>> encoding, >>>> > but you need to specify the encoding in Spring configuration external >>>> to the >>>> > .properties file. >>>> > >>>> > In my opinion it would cause unnecessary confusion amongst developers >>>> to use >>>> > any other encoding than the one defined by the official documentation >>>> for >>>> > Properties. >>>> > >>>> > Best regards, >>>> > Thomas >>>> > >>>> > >>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada >>>> wrote: >>>> >> >>>> >> I think it was true before Java 1.6 because Java standard library >>>> >> (java.util.ResourceBundle or java.util.Properties) only supported >>>> >> ISO-8859-1 encoding file. >>>> >> But they support any encoding after Java 1.6. There are some >>>> >> frameworks which can read .properties with any encoding. For example, >>>> >> Spring Framework can read .properties with any encoding. I think it's >>>> >> very useful to read UTF-8 directly for multibyte language country. >>>> >> >>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>> >> wrote: >>>> >> > Please correct me if I am wrong, but I have been under the >>>> impression >>>> >> > that >>>> >> > Java .properties files should always use encoding ISO-8859-1. >>>> Characters >>>> >> > not >>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make >>>> things >>>> >> > confusing to developers if another encoding is used here instead? >>>> >> > >>>> >> > >>>> >> > >>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>> >> > >>>> >> > >>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>> >> > >>>> >> > If alternate encodings are desired how about supporting the XML >>>> format >>>> >> > of >>>> >> > Properties? >>>> >> > >>>> >> > Best regards, >>>> >> > Thomas >>>> >> > >>>> >> > >>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>> sthorger at redhat.com> >>>> >> > wrote: >>>> >> >> >>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >>>> co-exist. >>>> >> >> >>>> >> >> We can allow specifying the encoding in a comment on the first >>>> line >>>> >> >> like >>>> >> >> this: >>>> >> >> >>>> >> >> # encoding=utf-8 >>>> >> >> key=value >>>> >> >> >>>> >> >> # encoding=iso-8859-1 >>>> >> >> key=value >>>> >> >> >>>> >> >> If the first line in the file doesn't contain the comment with the >>>> >> >> encoding then we should default to iso-8859-1 for backwards >>>> >> >> compatibility >>>> >> >> >>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada >>>> wrote: >>>> >> >>> >>>> >> >>> Thanks for your comment. >>>> >> >>> >>>> >> >>> > If we want to change to utf-8 we'd still need to support iso.. >>>> for >>>> >> >>> > backwards compatibility. >>>> >> >>> >>>> >> >>> If we change to UTF-8, we can still read unicode codepoint like >>>> >> >>> '\u00e8'. >>>> >> >>> There is an incompatibility when non-ascii characters are used in >>>> >> >>> message properties. >>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer >>>> codepage >>>> >> >>> layout: >>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>> >> >>> >>>> >> >>> I think the non-ascii characters might be used in French >>>> messages like >>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards compatibility. >>>> >> >>> To support this, I think we can add a property like >>>> "messageEncoding" >>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>> >> >>> >>>> >> >>> "theme": { >>>> >> >>> "staticMaxAge": 2592000, >>>> >> >>> "cacheTemplates": true, >>>> >> >>> "cacheThemes": true, >>>> >> >>> "messageEncoding": "ISO-8859-1", >>>> >> >>> "folder": { >>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>> >> >>> } >>>> >> >>> }, >>>> >> >>> >>>> >> >>> Regards, >>>> >> >>> >>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>> >> >>> >>>> >> >>> wrote: >>>> >> >>> > We have in the past discussed this and decided to stick with >>>> >> >>> > ISO-8859-1. >>>> >> >>> > That was probably not the best idea though. If we want to >>>> change to >>>> >> >>> > utf-8 >>>> >> >>> > we'd still need to support iso.. for backwards compatibility. >>>> >> >>> > >>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira >>>> wrote: >>>> >> >>> >> >>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>> >> >>> >> >>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>> >> >>> >> > Hello all, >>>> >> >>> >> > >>>> >> >>> >> > I am trying to translate all base theme messages to my >>>> country >>>> >> >>> >> > language, Japanese. And I'd like to contribute them. Before >>>> that >>>> >> >>> >> > work, >>>> >> >>> >> > I'd like to propose about the files encoding. >>>> >> >>> >> > >>>> >> >>> >> > Currently, the message files (*.properties) are loaded with >>>> >> >>> >> > ISO-8859-1 >>>> >> >>> >> > encoding. Therefore, it is necessary to convert the files by >>>> >> >>> >> > 'native2ascii' command beforehand. However we can directly >>>> read >>>> >> >>> >> > the >>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or later >>>> because >>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >>>> introduced >>>> >> >>> >> > as >>>> >> >>> >> > below. >>>> >> >>> >> > >>>> >> >>> >> > >>>> >> >>> >> > >>>> >> >>> >> > >>>> >> >>> >> > >>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>> >> >>> >> > >>>> >> >>> >> > So, my proposal is supporting the message files with UTF-8 >>>> >> >>> >> > encoding. >>>> >> >>> >> > I >>>> >> >>> >> > believe that it's very developers/customers friendly. In >>>> >> >>> >> > addition, >>>> >> >>> >> > we >>>> >> >>> >> > can easily review the translated messages on the github pull >>>> >> >>> >> > request >>>> >> >>> >> > view and so on. What do you think? >>>> >> >>> >> > >>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >>>> request. >>>> >> >>> >> > >>>> >> >>> >> > Regards, >>>> >> >>> >> > >>>> >> >>> >> > -- >>>> >> >>> >> > Hiroyuki Wada, >>>> >> >>> >> > Developer, >>>> >> >>> >> > Nomura Research Institute, Ltd. >>>> >> >>> >> > _______________________________________________ >>>> >> >>> >> > keycloak-dev mailing list >>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> >>> >> >>>> >> >>> >> -- >>>> >> >>> >> >>>> >> >>> >> abstractj >>>> >> >>> >> PGP: 0x84DC9914 >>>> >> >>> >> _______________________________________________ >>>> >> >>> >> 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 >>>> >> > >>>> >> > >>>> >> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> _______________________________________________ >>>> 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/20160707/8438f2c5/attachment-0001.html From psilva at redhat.com Thu Jul 7 16:02:21 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 7 Jul 2016 16:02:21 -0400 (EDT) Subject: [keycloak-dev] Tomcat 8 Arquillian Tests In-Reply-To: <577DFE9D.8090304@redhat.com> References: <1494239438.5788955.1467645005286.JavaMail.zimbra@redhat.com> <577DFE9D.8090304@redhat.com> Message-ID: <532186488.7785235.1467921741922.JavaMail.zimbra@redhat.com> Thanks. ----- Original Message ----- From: "Vlasta Ramik" To: keycloak-dev at lists.jboss.org Sent: Thursday, July 7, 2016 4:02:53 AM Subject: Re: [keycloak-dev] Tomcat 8 Arquillian Tests Hi Pedro, you need to build distribution first, if you already didn't so. mvn clean install -Pdistribution -DskipTests cd testsuite/integration-arquillian mvn clean install -Pauth-server-wildfly,app-server-tomcat8 -Dtest=Tomcat8DemoExampleAdapterTest or mvn clean install -Pdistribution,auth-server-wildfly,app-server-tomcat8 -Dtest=Tomcat8DemoExampleAdapterTest But currently tomcat tests fails because testsuite expects that server runs on port 8280, not tomcat default 8080. I'm working on it to fix this. Vlasta On 07/04/2016 05:10 PM, Pedro Igor Silva wrote: > Hi, > > Is that command correct in order to get adapter tests running against a Tomcat 8 app server ? > > mvn -Pauth-server-wildfly -Papp-server-tomcat8 -Pexamples clean install -Dtest=Tomcat8DemoExampleAdapterTest > > Regards. > Pedro Igor > _______________________________________________ > 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 From wadahiro at gmail.com Thu Jul 7 23:08:48 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Fri, 8 Jul 2016 12:08:48 +0900 Subject: [keycloak-dev] A minor bug in user detail screen Message-ID: Hello, I found a minor bug in user detail screen. Could I create a JIRA issue and send a PR? Steps to Reproduce: 1. Configure Identity Provider 2. Add new user 3. Open the user detail screen 4. Click 'Federation Link' label Expected Result: Nothing happened. Actual Result: 'User Enabled' toggled. Regards, -- Hiroyuki Wada From sthorger at redhat.com Fri Jul 8 01:19:25 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 8 Jul 2016 07:19:25 +0200 Subject: [keycloak-dev] A minor bug in user detail screen In-Reply-To: References: Message-ID: 'Federation Link' should only be shown for users that have a federation link which are users linked to a user federation provider. Is your user coming from LDAP or a custom user federation provider? I can see that the label is indeed incorrect and it has 'for="userEnabled"' which it should have. So please create a JIRA and PR for that. On 8 July 2016 at 05:08, Hiroyuki Wada wrote: > Hello, > > I found a minor bug in user detail screen. Could I create a JIRA issue > and send a PR? > > Steps to Reproduce: > 1. Configure Identity Provider > 2. Add new user > 3. Open the user detail screen > 4. Click 'Federation Link' label > > Expected Result: > Nothing happened. > > Actual Result: > 'User Enabled' toggled. > > > Regards, > > -- > Hiroyuki Wada > _______________________________________________ > 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/20160708/ecd1c957/attachment.html From wadahiro at gmail.com Fri Jul 8 02:00:35 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Fri, 8 Jul 2016 15:00:35 +0900 Subject: [keycloak-dev] A minor bug in user detail screen In-Reply-To: References: Message-ID: >Is your user coming from LDAP or a custom user federation provider? Yes. It needs to configure user federation and linking user to reproduce this bug. I created a JIRA issue and send a PR later. https://issues.jboss.org/browse/KEYCLOAK-3289 On Fri, Jul 8, 2016 at 2:19 PM, Stian Thorgersen wrote: > 'Federation Link' should only be shown for users that have a federation link > which are users linked to a user federation provider. Is your user coming > from LDAP or a custom user federation provider? > > I can see that the label is indeed incorrect and it has 'for="userEnabled"' > which it should have. So please create a JIRA and PR for that. > > On 8 July 2016 at 05:08, Hiroyuki Wada wrote: >> >> Hello, >> >> I found a minor bug in user detail screen. Could I create a JIRA issue >> and send a PR? >> >> Steps to Reproduce: >> 1. Configure Identity Provider >> 2. Add new user >> 3. Open the user detail screen >> 4. Click 'Federation Link' label >> >> Expected Result: >> Nothing happened. >> >> Actual Result: >> 'User Enabled' toggled. >> >> >> Regards, >> >> -- >> Hiroyuki Wada >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From thomas.darimont at googlemail.com Fri Jul 8 04:35:46 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 8 Jul 2016 10:35:46 +0200 Subject: [keycloak-dev] TokenEndpoint is potentially too restrictive Message-ID: Hello Group, I just found out that as long as a user has a required_action set up one cannot authenticate via grant_type password throught the TokenEndpoint because of this line in TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant if (user.getRequiredActions() != null && user.getRequiredActions().size() > 0) { event.error(Errors.RESOLVE_REQUIRED_ACTIONS); throw new ErrorResponseException("invalid_grant", "Account is not fully set up", Response.Status.BAD_REQUEST); } current master: https://github.com/keycloak/keycloak/blob/bd2887aa77184d82e795e4200eb55a3d9b11e4d4/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 1.9.x https://github.com/keycloak/keycloak/blob/e7822431fded5948a5e248766e6ffbf86d476cf8/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 I think that this is too restrictive. Imagine a default required action that has no user interaction but records some user login statistics like last login date, count logins, login failures etc. In this case it would be better to check if the configured required_action requires user-interaction (e.g. via a new method boolean isInteractive()) or communicate that required actions should not be used for actions that don't require user interactions - an authenticator is then probably the better choice. Cheers, Thomas I tested this with a required action like the LoginStatsRecordingRequiredActionProvider listed below. Now setup a client with the name test-client and a user with the name tester. With that deployed to keycloak as a default action one can use the following curl command to see the problem. KC_REALM=test-realm KC_USERNAME=tester KC_PASSWORD=test KC_CLIENT=test-client KC_CLIENT_SECRET=e9ca8fad-d399-4455-5290-817102e7f9ff KC_SERVER=192.168.99.1:8080 KC_CONTEXT=auth curl -k -v --noproxy 192.168.99.1 \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=password" \ -d "username=$KC_USERNAME" \ -d "password=$KC_PASSWORD" \ -d "client_id=$KC_CLIENT" \ -d "client_secret=$KC_CLIENT_SECRET" \ "http:// $KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" Gives: < HTTP/1.1 400 Bad Request < Connection: keep-alive < X-Powered-By: Undertow/1 < Server: WildFly/10 < Content-Type: application/json < Content-Length: 75 < Date: Fri, 08 Jul 2016 08:24:59 GMT {"error_description":"Account is not fully set up","error":"invalid_grant"} ---- package com.acme.keycloak.ext.authentication; import static java.util.Arrays.asList; import java.time.Instant; import java.time.LocalDateTime; import java.util.Arrays; import java.util.List; import java.util.TimeZone; import org.jboss.logging.Logger; import org.keycloak.Config.Scope; import org.keycloak.authentication.RequiredActionContext; import org.keycloak.authentication.RequiredActionFactory; import org.keycloak.authentication.RequiredActionProvider; import org.keycloak.models.KeycloakSession; import org.keycloak.models.KeycloakSessionFactory; import org.keycloak.models.UserLoginFailureModel; import org.keycloak.models.UserModel; /** * Collects information about User Login behaviour. *

* Collects the following: *

    *
  • Date / Time of first login
    • *
  • Date / Time of recent login
    • *
  • Count of logins since first login
    • *
  • Count of failed logins since the configured Failure Reset Time unter Security Defenses
    • *
*

* This {@link RequiredActionProvider} is Stateless and can be reused. * * @author tdarimont */ public class LoginStatsRecordingRequiredActionProvider implements RequiredActionProvider, RequiredActionFactory { private static final Logger LOG = Logger.getLogger(LoginStatsRecordingRequiredActionProvider.class); private static final String PROVIDER_ID = "login_stats_action"; private static final String RECORD_LOGIN_STATISTICS_ACTION = "Record Login Statistics Action"; private static final String LOGIN_LOGIN_COUNT = "login.login-count"; private static final String LOGIN_FAILED_LOGIN_COUNT = "login.failed-login-count"; private static final String LOGIN_FAILED_LOGIN_DATE = "login.failed-login-date"; private static final String LOGIN_FIRST_LOGIN_DATE = "login.first-login-date"; private static final String LOGIN_RECENT_LOGIN_DATE = "login.recent-login-date"; private static final String ONE = "1"; private static final String ZERO = "0"; private static final LoginStatsRecordingRequiredActionProvider INSTANCE = new LoginStatsRecordingRequiredActionProvider(); @Override public void close() { // NOOP } @Override public void evaluateTriggers(RequiredActionContext context) { UserModel user = context.getUser(); try { recordFirstLogin(user); } catch (Exception ex) { LOG.warnv(ex, "Couldn't record first login <{0}>", this); } try { recordRecentLogin(user); } catch (Exception ex) { LOG.warnv(ex, "Couldn't record recent login <{0}>", this); } try { recordLoginCount(user); } catch (Exception ex) { LOG.warnv(ex, "Couldn't record login count <{0}>", this); } try { recordFailedLogin(user, context); } catch (Exception ex) { LOG.warnv(ex, "Couldn't record failed login <{0}>", this); } } private void recordFailedLogin(UserModel user, RequiredActionContext context) { UserLoginFailureModel loginFailures = context.getSession().sessions() .getUserLoginFailure(context.getRealm(), user.getUsername()); if (loginFailures != null) { user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, Arrays.asList(String.valueOf(loginFailures.getNumFailures()))); user.setAttribute(LOGIN_FAILED_LOGIN_DATE, Arrays.asList(getLocalDateTimeFromTimestamp(loginFailures.getLastFailure()).toString())); } else { user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, Arrays.asList(ZERO)); } } private void recordLoginCount(UserModel user) { List list = user.getAttribute(LOGIN_LOGIN_COUNT); if (list == null || list.isEmpty()) { list = asList(ONE); } else { list = asList(String.valueOf(Long.parseLong(list.get(0)) + 1)); } user.setAttribute(LOGIN_LOGIN_COUNT, list); } private void recordRecentLogin(UserModel user) { user.setAttribute(LOGIN_RECENT_LOGIN_DATE, asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); } private void recordFirstLogin(UserModel user) { List list = user.getAttribute(LOGIN_FIRST_LOGIN_DATE); if (list == null || list.isEmpty()) { user.setAttribute(LOGIN_FIRST_LOGIN_DATE, asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); } } @Override public void requiredActionChallenge(RequiredActionContext context) { // NOOP } @Override public void processAction(RequiredActionContext context) { context.success(); } @Override public RequiredActionProvider create(KeycloakSession session) { return INSTANCE; } @Override public void init(Scope config) { LOG.infov("Creating IdM Keycloak extension <{0}>", this); // NOOP } @Override public void postInit(KeycloakSessionFactory factory) { // NOOP } @Override public String getId() { return PROVIDER_ID; } @Override public String getDisplayText() { return RECORD_LOGIN_STATISTICS_ACTION; } private LocalDateTime getLocalDateTimeFromTimestamp(long timestampMillis) { return LocalDateTime.ofInstant(Instant.ofEpochSecond(timestampMillis / 1000), TimeZone.getDefault().toZoneId()); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160708/23079270/attachment-0001.html From gambol99 at gmail.com Fri Jul 8 04:59:35 2016 From: gambol99 at gmail.com (gambol) Date: Fri, 8 Jul 2016 09:59:35 +0100 Subject: [keycloak-dev] Keycloak SSL Reverse Proxy settings Message-ID: Hiya We've been running v1.9.2 behind a nginx proxy for some time now. Has the setup for running Keycloak v2.0.0-Final behind a proxy changed? ... We've kept the amended lines, but Keycloak is returns content in non-https appearing to ignore the X-Forwarded-Proto ? ... <--- ... ------------------------------ But looking at the urls handed back, they are all http:// Doing a tcpdump dump between proxy and keycloak, I can see the X-Forwarded headers added by the proxy GET /auth/admin/master/console/ HTTP/1.0 X-Real-IP: 127.0.0.1 X-Forwarded-For: 127.0.0.1 X-Forwarded-Proto: https Host: 127.0.0.1 Connection: close Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/* ;q=0.8 Accept-Encoding: gzip, deflate, sdch, br Accept-Language: en-US,en;q=0.8 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160708/5ba4b368/attachment.html From mposolda at redhat.com Fri Jul 8 07:39:43 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 8 Jul 2016 13:39:43 +0200 Subject: [keycloak-dev] TokenEndpoint is potentially too restrictive In-Reply-To: References: Message-ID: <577F90FF.6050006@redhat.com> There was already some quite a long discussion about similar stuff. It was about consents though, not about required actions. However IMO both consents and requiredActions are quite similar thing and it's by design that user is not able to login with directGrant if he has either consent or requiredAction on himself. However when I look at your particular use-case, it seems that you are using LoginStatsRecordingRequiredActionProvider as an interceptor, which doesn't need any real requiredAction on user, but you just want to ensure that "evaluateTriggers" is called after each user login. Is it correct? Then you can just check your requiredAction provider as "enabled", but NOT as "default" . Note that "evaluateTriggers" will be always invoked for every user after his login even if user doesn't have the particular action on him. The purpose of "evaluateTriggers" is actually to check, if requiredAction should be added to the user if some specific conditions occurs. For example see VerifyEmail.evaluateTriggers, which adds the VERIFY_EMAIL requiredAction to user if he doesn't yet have verified email. Marek On 08/07/16 10:35, Thomas Darimont wrote: > Hello Group, > > I just found out that as long as a user has a required_action set up > one cannot authenticate via grant_type password throught the > TokenEndpoint > because of this line in > TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant > > if (user.getRequiredActions() != null && > user.getRequiredActions().size() > 0) { > event.error(Errors.RESOLVE_REQUIRED_ACTIONS); > throw new ErrorResponseException("invalid_grant", "Account is not > fully set up", Response.Status.BAD_REQUEST); > } > > current master: > https://github.com/keycloak/keycloak/blob/bd2887aa77184d82e795e4200eb55a3d9b11e4d4/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 > > 1.9.x > https://github.com/keycloak/keycloak/blob/e7822431fded5948a5e248766e6ffbf86d476cf8/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 > > I think that this is too restrictive. Imagine a default required > action that has no user interaction but records some user login > statistics like > last login date, count logins, login failures etc. > In this case it would be better to check if the configured > required_action requires user-interaction (e.g. via a new method > boolean isInteractive()) > or communicate that required actions should not be used for actions > that don't require user interactions - an authenticator is then > probably the better choice. > > Cheers, > Thomas > > I tested this with a required action like the > LoginStatsRecordingRequiredActionProvider listed below. > Now setup a client with the name test-client and a user with the name > tester. > > With that deployed to keycloak as a default action one can use the > following curl command > to see the problem. > > KC_REALM=test-realm > KC_USERNAME=tester > KC_PASSWORD=test > KC_CLIENT=test-client > KC_CLIENT_SECRET=e9ca8fad-d399-4455-5290-817102e7f9ff > KC_SERVER=192.168.99.1:8080 > KC_CONTEXT=auth > > curl -k -v --noproxy 192.168.99.1 \ > -H "Content-Type: application/x-www-form-urlencoded" \ > -d "grant_type=password" \ > -d "username=$KC_USERNAME" \ > -d "password=$KC_PASSWORD" \ > -d "client_id=$KC_CLIENT" \ > -d "client_secret=$KC_CLIENT_SECRET" \ > "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" > > Gives: > < HTTP/1.1 400 Bad Request > < Connection: keep-alive > < X-Powered-By: Undertow/1 > < Server: WildFly/10 > < Content-Type: application/json > < Content-Length: 75 > < Date: Fri, 08 Jul 2016 08:24:59 GMT > {"error_description":"Account is not fully set > up","error":"invalid_grant"} > > > ---- > > > package com.acme.keycloak.ext.authentication; > > import static java.util.Arrays.asList; > > import java.time.Instant; > import java.time.LocalDateTime; > import java.util.Arrays; > import java.util.List; > import java.util.TimeZone; > > import org.jboss.logging.Logger; > import org.keycloak.Config.Scope; > import org.keycloak.authentication.RequiredActionContext; > import org.keycloak.authentication.RequiredActionFactory; > import org.keycloak.authentication.RequiredActionProvider; > import org.keycloak.models.KeycloakSession; > import org.keycloak.models.KeycloakSessionFactory; > import org.keycloak.models.UserLoginFailureModel; > import org.keycloak.models.UserModel; > > /** > * Collects information about User Login behaviour. > *

> * Collects the following: > *

    > *
  • Date / Time of first login
    • > *
  • Date / Time of recent login
    • > *
  • Count of logins since first login
    • > *
  • Count of failed logins since the configured Failure Reset > Time unter Security Defenses
    • > *
> *

> * This {@link RequiredActionProvider} is Stateless and can be reused. > * > * @author tdarimont > */ > public class LoginStatsRecordingRequiredActionProvider implements > RequiredActionProvider, RequiredActionFactory { > > private static final Logger LOG = > Logger.getLogger(LoginStatsRecordingRequiredActionProvider.class); > > private static final String PROVIDER_ID = "login_stats_action"; > private static final String RECORD_LOGIN_STATISTICS_ACTION = "Record > Login Statistics Action"; > > private static final String LOGIN_LOGIN_COUNT = "login.login-count"; > private static final String LOGIN_FAILED_LOGIN_COUNT = > "login.failed-login-count"; > private static final String LOGIN_FAILED_LOGIN_DATE = > "login.failed-login-date"; > > private static final String LOGIN_FIRST_LOGIN_DATE = > "login.first-login-date"; > private static final String LOGIN_RECENT_LOGIN_DATE = > "login.recent-login-date"; > > private static final String ONE = "1"; > private static final String ZERO = "0"; > > private static final LoginStatsRecordingRequiredActionProvider > INSTANCE = new LoginStatsRecordingRequiredActionProvider(); > > @Override > public void close() { > // NOOP > } > > @Override > public void evaluateTriggers(RequiredActionContext context) { > > UserModel user = context.getUser(); > > try { > recordFirstLogin(user); > } catch (Exception ex) { > LOG.warnv(ex, "Couldn't record first login <{0}>", this); > } > > try { > recordRecentLogin(user); > } catch (Exception ex) { > LOG.warnv(ex, "Couldn't record recent login <{0}>", this); > } > > try { > recordLoginCount(user); > } catch (Exception ex) { > LOG.warnv(ex, "Couldn't record login count <{0}>", this); > } > > try { > recordFailedLogin(user, context); > } catch (Exception ex) { > LOG.warnv(ex, "Couldn't record failed login <{0}>", this); > } > } > > private void recordFailedLogin(UserModel user, RequiredActionContext > context) { > > UserLoginFailureModel loginFailures = context.getSession().sessions() > .getUserLoginFailure(context.getRealm(), user.getUsername()); > > if (loginFailures != null) { > user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, > Arrays.asList(String.valueOf(loginFailures.getNumFailures()))); > user.setAttribute(LOGIN_FAILED_LOGIN_DATE, > Arrays.asList(getLocalDateTimeFromTimestamp(loginFailures.getLastFailure()).toString())); > } else { > user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, Arrays.asList(ZERO)); > } > } > > private void recordLoginCount(UserModel user) { > > List list = user.getAttribute(LOGIN_LOGIN_COUNT); > > if (list == null || list.isEmpty()) { > list = asList(ONE); > } else { > list = asList(String.valueOf(Long.parseLong(list.get(0)) + 1)); > } > > user.setAttribute(LOGIN_LOGIN_COUNT, list); > } > > private void recordRecentLogin(UserModel user) { > user.setAttribute(LOGIN_RECENT_LOGIN_DATE, > asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); > } > > private void recordFirstLogin(UserModel user) { > > List list = user.getAttribute(LOGIN_FIRST_LOGIN_DATE); > > if (list == null || list.isEmpty()) { > user.setAttribute(LOGIN_FIRST_LOGIN_DATE, > asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); > } > } > > @Override > public void requiredActionChallenge(RequiredActionContext context) { > // NOOP > } > > @Override > public void processAction(RequiredActionContext context) { > context.success(); > } > > @Override > public RequiredActionProvider create(KeycloakSession session) { > return INSTANCE; > } > > @Override > public void init(Scope config) { > LOG.infov("Creating IdM Keycloak extension <{0}>", this); > // NOOP > } > > @Override > public void postInit(KeycloakSessionFactory factory) { > // NOOP > } > > @Override > public String getId() { > return PROVIDER_ID; > } > > @Override > public String getDisplayText() { > return RECORD_LOGIN_STATISTICS_ACTION; > } > > private LocalDateTime getLocalDateTimeFromTimestamp(long > timestampMillis) { > return LocalDateTime.ofInstant(Instant.ofEpochSecond(timestampMillis / > 1000), TimeZone.getDefault().toZoneId()); > } > } > > > > _______________________________________________ > 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/20160708/dd326215/attachment-0001.html From mposolda at redhat.com Fri Jul 8 08:07:48 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 8 Jul 2016 14:07:48 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> <5776C857.2070703@redhat.com> <577E08A0.4010409@redhat.com> Message-ID: <577F9794.6060904@redhat.com> On 07/07/16 12:07, Stian Thorgersen wrote: > > > On 7 July 2016 at 09:45, Marek Posolda > wrote: > > On 04/07/16 09:47, Stian Thorgersen wrote: >> ScopeAggregatorProtocolMapper sounds interesting, but I'm not >> quite sure how it would look like to an end-user. >> >> * Are these managed on a separate screen or on the protocol >> mappers screen? > I am thinking about the protocolMappers screen. Just add another > "type" of protocolMapper. This means that we don't need to add > another concept/modelType just for scope parameter, but still we > can easily filter/view the available mappers of type 'scope > aggregator' (on the screen with list of all protocolMappers). > > > Not quite sure I see why it should be on the protocol mappers screen. > As it's a separate type of mapper as well the UI to define them would > be different I'm not sure I see why it can't be a separate screen. > > I think it would fit better on the scope tab. It could have two tabs > "Default scope" and "Scopes" or something like that. Not sure which place is better. However I am maybe slightly more for protocolMappers screen because: - It just looks a bit more intuitive to me if all the things, which are represented at model/DB level by protocolMapper entity are also in admin console grouped together on single place. But maybe it's just me ;-) - For the aggregated mapper, you can select that "children" mappers will be either simple mappers or other aggregated mappers. For example for the "full-profile" mapper, you can select that it's child is another aggregated mapper "profile" together with some additional simple mappers like "first_name" or "last_name" . Hence in the list of available mappers, you should be able to see both simple and aggregated mappers. Isn't it then a bit confusing that you will see both the simple mappers like "firstName" (which are configured in "mappers" tab) together with aggregated mappers like "profile" (which are configured under "scope/default scope" tab) together? Btv. Our current providerModel classes usually have something like: Map config; on them. However for the aggregated mapper impl, it may be needed to extend this to: Map> config; as mapper will need to have the property with the list of children mappers and property with the list of children roles. The question is, how to represent it in DB? I can see possibilities like: a) The value at DB level will be just simple string with children values divided by some delimiter (eg. "mapper123###mapper456###mapper789" ) b) The value will be list at DB level with separate record for every value (eg. 3 values like "mapper123" , "mapper456" , "mapper789" ) It seems the (b) is a bit harder for migration, but likely the more proper way to address this? It looks like something to keep in mind once we refactor to the "unified" providerModel table. > >> * How do users define and view scopes, including viewing what >> claims/mappers/roles are associated with a scope? >> * How does a user add/remove claims, protocol mappers and roles >> to a ScopeAggregatorProtocolMapper? > I am thinking that for roles, you will select the roles in same > way, like it's in current "Scopes" tab of client (or "role > mappings" tab of user). Probably very similar UI can be used for > selecting "children" mappers of current protocolMapper though? > Something like "Available mappers" and "Assigned mappers" and > buttons like "Add selected" and "Remove selected". Also similarly > like for roles, you can view in "Effective mappers" the list of > all effective mappers in case that you have more composed > aggregated scopeAggregatorMappers. > > For example, if you have mapper for scope parameter > "full-profile", which will have children mappers, that will point > to other scope aggregated mappers : "profile" , "email" and > "phone". Hence in "Effective mappers" for "full-profile" you will > see all the descendants, not just the direct children. So you will > see also all the simple attribute mappers like "firstName", > "lastName", "birthday", "phone number", ... > > > Sounds good > > >> * Do we provide one or more built-in >> ScopeAggregatorProtocolMapper that are configurable? I assume so >> and that users don't have to programatically define scopes. > Yes. I think that we should provide those built-in, which are > specified by OIDC specification. Which is "profile" , "email" , > "phone" , "address". And we will need to define mappers for all > their simple attributes ( "birthday", "gender" , ...) . Those > simple mappers like "birthday" won't be root mappers by default, > so they won't be applied unless the scope parameter is used (for > their parent scopeAggregatorMapper). > > For backwards compatibility, we will still use the same 'simple' > mappers like now ( username, email, full name, family name, given > name) and they will be added to token by default. The > scopeAggregator mappers (and their corresponding children) will be > applied just if the scope parameter with corresponding value will > be used. > > > SAML doesn't have this concept does it? If so it probably doesn't even > make sense to show scope mappers for SAML clients. I don't think that SAML has something like scope parameter. At least I am not aware of that :-) However our SAML clients currently have "Scope" tab visible to map which realm roles (or client roles) are allowed to be put into SAML assertion. That works same like for OIDC clients and makes sense to keep. I guess you meant to hide just the new sub-tab of the "Scope" tab for configure scope parameter? Marek > > >> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper? > Yes (see above) > > Marek > >> >> On 1 July 2016 at 21:45, Marek Posolda > > wrote: >> >> Ok, I wasn't also 100% keen about using role. >> >> Thinking also about what Pedro mentioned before about >> protocol mappers. So I wonder that instead of introduce new >> "scope" concept, we just reuse protocolMappers SPI and have >> special impl of protocolMapper, which is able to deal with >> scope parameter and aggregate other "children" >> protocolMappers and roles? >> >> Something like this: >> - There will be new ProtocolMapper implementation like >> ScopeAggregatorProtocolMapper. You will define value of >> scope parameter (eg. "photo" ) in the configuration of this >> protocolMapper. Mapper will be ignored if scope parameter >> value with this name was not used. >> >> - You will be able to define "children" protocolMappers and >> "children" roles in ScopeAggregatorProtocolMapper. >> >> - For each client (and clientTemplate), we will have many >> defined protocolMappers, but just some subset of them are >> "root" mappers, which are applied by default. The rest of >> mappers will be used just as "children" of root mappers. So >> in client model, we might have: >> client.getDefinedProtocolMappers() // all defined >> client.getProtocolMappers() // just subset of defined >> (defacto root mappers) >> >> - For example: client will have defined protocolMappers: >> firstName, lastName, birthday, profile, email. Just "profile" >> and "email" will be root mappers. And "profile" is >> ScopeAggregatorMapper for scope value "profile" and it's >> children mappers are : firstName, lastName, birthday. >> >> So then: >> -- user will send "scope=profile" . Then defacto all of >> "firstName", "lastName", "birthday", "email" claims will be >> included in token. On consent screen will be just "Profile" >> and "Email" >> -- user won't send "scope=profile" . Then defacto just >> "email" claim will be included (So for this example, email is >> always included even if not specified by scope parameter). >> >> - With this concept, we are able to aggregate many various >> claims into single value of "scope" and on the consent screen >> have just the roots. This would fit well for the default >> scope values mentioned by OIDC specs. We are also able to >> define mappers (claims), which will be always available even >> if not specified by scope parameter. >> >> - For the roles, I am not 100% sure whether to include them >> into the concept or not? However it seems to me that rather >> yes. The particular role will be applied into token just if >> all of those 3 conditions are met: >> 1) user is member of the role >> 2) client has scope for the role (so current "scope" tab in >> clients will remain as is) >> 3) if role has scopePAramRequired=true, then it must be >> included in some mapper (in other words, those roles are not >> included directly in clientSession.getRoles , but it's the >> responsibility of ScopeAggregatorProtocolMapper to add them >> into token if conditions 1+2 are met). >> >> So again, user won't see all children roles on consent >> screen. Just the parent protocolMapper. >> >> This will work fine with "scope=offline_access" . There will >> be protocolMapper for "offline_access" parameter, which will >> aggregate just one children role (the current realm role >> "offline_access"). The offline token will be issued just if >> accessToken will have "offline_access" permission. So if some >> client, doesn't need offline tokens, it can just remove >> "offline_access" protocolMapper. Also if some user shouldn't >> be allowed to request offline tokens, admin can remove him >> from the "offline_access" role. >> >> - If some scope parameter is applicable for more clients, it >> can be defined on clientTemplate. >> >> >> PS: I will be on holidays and back on next Thursday 7th July. >> So sorry if I won't reply immediately to next mails. >> >> Mare >> >> >> >> On 01/07/16 14:57, Pedro Igor Silva wrote: >> >> Reading all of this makes me think it would be >> cleaner to introduce a >> separate scope concept ;) >> >> A user doesn't have a scope - a user has roles and >> attributes. Re-using roles >> concept for the scope just makes it feel awkward and >> retrofitted. >> >> +10000 >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160708/442ffde5/attachment-0001.html From thomas.darimont at googlemail.com Fri Jul 8 08:13:18 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 8 Jul 2016 14:13:18 +0200 Subject: [keycloak-dev] TokenEndpoint is potentially too restrictive In-Reply-To: <577F90FF.6050006@redhat.com> References: <577F90FF.6050006@redhat.com> Message-ID: Thanks Marek, that makes sense now. Removing the "default" checkbox on my provider did the trick - yes I want to execute this action for every user regardless on login in the sense of an filter / interceptor. Btw. this use case I implemented is IMHO quite common - would be cool if keycloak would ship with something like that out-of-the-box ;-) Cheers, Thomas 2016-07-08 13:39 GMT+02:00 Marek Posolda : > There was already some quite a long discussion about similar stuff. It was > about consents though, not about required actions. However IMO both > consents and requiredActions are quite similar thing and it's by design > that user is not able to login with directGrant if he has either consent or > requiredAction on himself. > > However when I look at your particular use-case, it seems that you are > using LoginStatsRecordingRequiredActionProvider as an interceptor, which > doesn't need any real requiredAction on user, but you just want to ensure > that "evaluateTriggers" is called after each user login. Is it correct? > > Then you can just check your requiredAction provider as "enabled", but NOT > as "default" . Note that "evaluateTriggers" will be always invoked for > every user after his login even if user doesn't have the particular action > on him. The purpose of "evaluateTriggers" is actually to check, if > requiredAction should be added to the user if some specific conditions > occurs. For example see VerifyEmail.evaluateTriggers , which adds the > VERIFY_EMAIL requiredAction to user if he doesn't yet have verified email. > > Marek > > > On 08/07/16 10:35, Thomas Darimont wrote: > > Hello Group, > > I just found out that as long as a user has a required_action set up one > cannot authenticate via grant_type password throught the TokenEndpoint > because of this line in > TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant > > if (user.getRequiredActions() != null && user.getRequiredActions().size() > > 0) { > event.error(Errors.RESOLVE_REQUIRED_ACTIONS); > throw new ErrorResponseException("invalid_grant", "Account is not fully > set up", Response.Status.BAD_REQUEST); > } > > current master: > > https://github.com/keycloak/keycloak/blob/bd2887aa77184d82e795e4200eb55a3d9b11e4d4/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 > > 1.9.x > > https://github.com/keycloak/keycloak/blob/e7822431fded5948a5e248766e6ffbf86d476cf8/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 > > I think that this is too restrictive. Imagine a default required action > that has no user interaction but records some user login statistics like > last login date, count logins, login failures etc. > In this case it would be better to check if the configured required_action > requires user-interaction (e.g. via a new method boolean isInteractive()) > or communicate that required actions should not be used for actions that > don't require user interactions - an authenticator is then probably the > better choice. > > Cheers, > Thomas > > I tested this with a required action like the > LoginStatsRecordingRequiredActionProvider listed below. > Now setup a client with the name test-client and a user with the name > tester. > > With that deployed to keycloak as a default action one can use the > following curl command > to see the problem. > > KC_REALM=test-realm > KC_USERNAME=tester > KC_PASSWORD=test > KC_CLIENT=test-client > KC_CLIENT_SECRET=e9ca8fad-d399-4455-5290-817102e7f9ff > KC_SERVER=192.168.99.1:8080 > KC_CONTEXT=auth > > curl -k -v --noproxy 192.168.99.1 \ > -H "Content-Type: application/x-www-form-urlencoded" \ > -d "grant_type=password" \ > -d "username=$KC_USERNAME" \ > -d "password=$KC_PASSWORD" \ > -d "client_id=$KC_CLIENT" \ > -d "client_secret=$KC_CLIENT_SECRET" \ > > "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" > > > Gives: > < HTTP/1.1 400 Bad Request > < Connection: keep-alive > < X-Powered-By: Undertow/1 > < Server: WildFly/10 > < Content-Type: application/json > < Content-Length: 75 > < Date: Fri, 08 Jul 2016 08:24:59 GMT > {"error_description":"Account is not fully set up","error":"invalid_grant"} > > > ---- > > > package com.acme.keycloak.ext.authentication; > > import static java.util.Arrays.asList; > > import java.time.Instant; > import java.time.LocalDateTime; > import java.util.Arrays; > import java.util.List; > import java.util.TimeZone; > > import org.jboss.logging.Logger; > import org.keycloak.Config.Scope; > import org.keycloak.authentication.RequiredActionContext; > import org.keycloak.authentication.RequiredActionFactory; > import org.keycloak.authentication.RequiredActionProvider; > import org.keycloak.models.KeycloakSession; > import org.keycloak.models.KeycloakSessionFactory; > import org.keycloak.models.UserLoginFailureModel; > import org.keycloak.models.UserModel; > > /** > * Collects information about User Login behaviour. > *

> * Collects the following: > *

    > *
  • Date / Time of first login
    • > *
  • Date / Time of recent login
    • > *
  • Count of logins since first login
    • > *
  • Count of failed logins since the configured Failure Reset > Time unter Security Defenses
    • > *
> *

> * This {@link RequiredActionProvider} is Stateless and can be reused. > * > * @author tdarimont > */ > public class LoginStatsRecordingRequiredActionProvider implements > RequiredActionProvider, RequiredActionFactory { > > private static final Logger LOG = > Logger.getLogger(LoginStatsRecordingRequiredActionProvider.class); > > private static final String PROVIDER_ID = "login_stats_action"; > private static final String RECORD_LOGIN_STATISTICS_ACTION = "Record Login > Statistics Action"; > > private static final String LOGIN_LOGIN_COUNT = "login.login-count"; > private static final String LOGIN_FAILED_LOGIN_COUNT = > "login.failed-login-count"; > private static final String LOGIN_FAILED_LOGIN_DATE = > "login.failed-login-date"; > > private static final String LOGIN_FIRST_LOGIN_DATE = > "login.first-login-date"; > private static final String LOGIN_RECENT_LOGIN_DATE = > "login.recent-login-date"; > > private static final String ONE = "1"; > private static final String ZERO = "0"; > > private static final LoginStatsRecordingRequiredActionProvider INSTANCE = > new LoginStatsRecordingRequiredActionProvider(); > > @Override > public void close() { > // NOOP > } > > @Override > public void evaluateTriggers(RequiredActionContext context) { > > UserModel user = context.getUser(); > > try { > recordFirstLogin(user); > } catch (Exception ex) { > LOG.warnv(ex, "Couldn't record first login <{0}>", this); > } > > try { > recordRecentLogin(user); > } catch (Exception ex) { > LOG.warnv(ex, "Couldn't record recent login <{0}>", this); > } > > try { > recordLoginCount(user); > } catch (Exception ex) { > LOG.warnv(ex, "Couldn't record login count <{0}>", this); > } > > try { > recordFailedLogin(user, context); > } catch (Exception ex) { > LOG.warnv(ex, "Couldn't record failed login <{0}>", this); > } > } > > private void recordFailedLogin(UserModel user, RequiredActionContext > context) { > > UserLoginFailureModel loginFailures = context.getSession().sessions() > .getUserLoginFailure(context.getRealm(), user.getUsername()); > > if (loginFailures != null) { > user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, > Arrays.asList(String.valueOf(loginFailures.getNumFailures()))); > user.setAttribute(LOGIN_FAILED_LOGIN_DATE, > > Arrays.asList(getLocalDateTimeFromTimestamp(loginFailures.getLastFailure()).toString())); > } else { > user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, Arrays.asList(ZERO)); > } > } > > private void recordLoginCount(UserModel user) { > > List list = user.getAttribute(LOGIN_LOGIN_COUNT); > > if (list == null || list.isEmpty()) { > list = asList(ONE); > } else { > list = asList(String.valueOf(Long.parseLong(list.get(0)) + 1)); > } > > user.setAttribute(LOGIN_LOGIN_COUNT, list); > } > > private void recordRecentLogin(UserModel user) { > user.setAttribute(LOGIN_RECENT_LOGIN_DATE, > > asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); > } > > private void recordFirstLogin(UserModel user) { > > List list = user.getAttribute(LOGIN_FIRST_LOGIN_DATE); > > if (list == null || list.isEmpty()) { > user.setAttribute(LOGIN_FIRST_LOGIN_DATE, > > asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); > } > } > > @Override > public void requiredActionChallenge(RequiredActionContext context) { > // NOOP > } > > @Override > public void processAction(RequiredActionContext context) { > context.success(); > } > > @Override > public RequiredActionProvider create(KeycloakSession session) { > return INSTANCE; > } > > @Override > public void init(Scope config) { > LOG.infov("Creating IdM Keycloak extension <{0}>", this); > // NOOP > } > > @Override > public void postInit(KeycloakSessionFactory factory) { > // NOOP > } > > @Override > public String getId() { > return PROVIDER_ID; > } > > @Override > public String getDisplayText() { > return RECORD_LOGIN_STATISTICS_ACTION; > } > > private LocalDateTime getLocalDateTimeFromTimestamp(long timestampMillis) { > return LocalDateTime.ofInstant(Instant.ofEpochSecond(timestampMillis / > 1000), TimeZone.getDefault().toZoneId()); > } > } > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160708/d327e437/attachment-0001.html From mitya at cargosoft.ru Sun Jul 10 13:46:15 2016 From: mitya at cargosoft.ru (Mitya) Date: Sun, 10 Jul 2016 20:46:15 +0300 Subject: [keycloak-dev] Disabling error notification in admin console Message-ID: <1468172775.31604.7.camel@cargosoft.ru> Hi, By default, if admin console receives a HTTP 500 from any underlying REST resource, it will pop up a small notification (implemented by errorInterceptor, app.js:1775). I'm developing a KeyCloak extension that includes a custom REST resource and adds GUI elements to admin console. Instead of standard notification, I'd like to pop up a modal dialog with verbose error description received from the server. Everything works fine (with $modal.open), but that default notification lingers behind my dialog. I know it's a purely cosmetic issue, but still a bit annoying. Is there any way to get rid of that notification in case modal dialog is used? Thx, Mitya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160710/69304f84/attachment.html From sthorger at redhat.com Mon Jul 11 02:08:25 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 11 Jul 2016 08:08:25 +0200 Subject: [keycloak-dev] TokenEndpoint is potentially too restrictive In-Reply-To: References: <577F90FF.6050006@redhat.com> Message-ID: Would it not be better to use an event listener for this? On 8 July 2016 at 14:13, Thomas Darimont wrote: > Thanks Marek, that makes sense now. > > Removing the "default" checkbox on my provider did the trick - yes I want > to execute this action for every user regardless on login in the sense of > an filter / interceptor. > > Btw. this use case I implemented is IMHO quite common - would be cool if > keycloak would ship with something like that out-of-the-box ;-) > > Cheers, > Thomas > > 2016-07-08 13:39 GMT+02:00 Marek Posolda : > >> There was already some quite a long discussion about similar stuff. It >> was about consents though, not about required actions. However IMO both >> consents and requiredActions are quite similar thing and it's by design >> that user is not able to login with directGrant if he has either consent or >> requiredAction on himself. >> >> However when I look at your particular use-case, it seems that you are >> using LoginStatsRecordingRequiredActionProvider as an interceptor, which >> doesn't need any real requiredAction on user, but you just want to ensure >> that "evaluateTriggers" is called after each user login. Is it correct? >> >> Then you can just check your requiredAction provider as "enabled", but >> NOT as "default" . Note that "evaluateTriggers" will be always invoked for >> every user after his login even if user doesn't have the particular action >> on him. The purpose of "evaluateTriggers" is actually to check, if >> requiredAction should be added to the user if some specific conditions >> occurs. For example see VerifyEmail.evaluateTriggers , which adds the >> VERIFY_EMAIL requiredAction to user if he doesn't yet have verified email. >> >> Marek >> >> >> On 08/07/16 10:35, Thomas Darimont wrote: >> >> Hello Group, >> >> I just found out that as long as a user has a required_action set up one >> cannot authenticate via grant_type password throught the TokenEndpoint >> because of this line in >> TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant >> >> if (user.getRequiredActions() != null && user.getRequiredActions().size() >> > 0) { >> event.error(Errors.RESOLVE_REQUIRED_ACTIONS); >> throw new ErrorResponseException("invalid_grant", "Account is not >> fully set up", Response.Status.BAD_REQUEST); >> } >> >> current master: >> >> https://github.com/keycloak/keycloak/blob/bd2887aa77184d82e795e4200eb55a3d9b11e4d4/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 >> >> 1.9.x >> >> https://github.com/keycloak/keycloak/blob/e7822431fded5948a5e248766e6ffbf86d476cf8/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 >> >> I think that this is too restrictive. Imagine a default required action >> that has no user interaction but records some user login statistics like >> last login date, count logins, login failures etc. >> In this case it would be better to check if the configured >> required_action requires user-interaction (e.g. via a new method boolean >> isInteractive()) >> or communicate that required actions should not be used for actions that >> don't require user interactions - an authenticator is then probably the >> better choice. >> >> Cheers, >> Thomas >> >> I tested this with a required action like the >> LoginStatsRecordingRequiredActionProvider listed below. >> Now setup a client with the name test-client and a user with the name >> tester. >> >> With that deployed to keycloak as a default action one can use the >> following curl command >> to see the problem. >> >> KC_REALM=test-realm >> KC_USERNAME=tester >> KC_PASSWORD=test >> KC_CLIENT=test-client >> KC_CLIENT_SECRET=e9ca8fad-d399-4455-5290-817102e7f9ff >> KC_SERVER=192.168.99.1:8080 >> KC_CONTEXT=auth >> >> curl -k -v --noproxy 192.168.99.1 \ >> -H "Content-Type: application/x-www-form-urlencoded" \ >> -d "grant_type=password" \ >> -d "username=$KC_USERNAME" \ >> -d "password=$KC_PASSWORD" \ >> -d "client_id=$KC_CLIENT" \ >> -d "client_secret=$KC_CLIENT_SECRET" \ >> >> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" >> >> >> Gives: >> < HTTP/1.1 400 Bad Request >> < Connection: keep-alive >> < X-Powered-By: Undertow/1 >> < Server: WildFly/10 >> < Content-Type: application/json >> < Content-Length: 75 >> < Date: Fri, 08 Jul 2016 08:24:59 GMT >> {"error_description":"Account is not fully set >> up","error":"invalid_grant"} >> >> >> ---- >> >> >> package com.acme.keycloak.ext.authentication; >> >> import static java.util.Arrays.asList; >> >> import java.time.Instant; >> import java.time.LocalDateTime; >> import java.util.Arrays; >> import java.util.List; >> import java.util.TimeZone; >> >> import org.jboss.logging.Logger; >> import org.keycloak.Config.Scope; >> import org.keycloak.authentication.RequiredActionContext; >> import org.keycloak.authentication.RequiredActionFactory; >> import org.keycloak.authentication.RequiredActionProvider; >> import org.keycloak.models.KeycloakSession; >> import org.keycloak.models.KeycloakSessionFactory; >> import org.keycloak.models.UserLoginFailureModel; >> import org.keycloak.models.UserModel; >> >> /** >> * Collects information about User Login behaviour. >> *

>> * Collects the following: >> *

    >> *
  • Date / Time of first login
    • >> *
  • Date / Time of recent login
    • >> *
  • Count of logins since first login
    • >> *
  • Count of failed logins since the configured Failure Reset >> Time unter Security Defenses
    • >> *
>> *

>> * This {@link RequiredActionProvider} is Stateless and can be reused. >> * >> * @author tdarimont >> */ >> public class LoginStatsRecordingRequiredActionProvider implements >> RequiredActionProvider, RequiredActionFactory { >> >> private static final Logger LOG = >> Logger.getLogger(LoginStatsRecordingRequiredActionProvider.class); >> >> private static final String PROVIDER_ID = "login_stats_action"; >> private static final String RECORD_LOGIN_STATISTICS_ACTION = "Record >> Login Statistics Action"; >> >> private static final String LOGIN_LOGIN_COUNT = "login.login-count"; >> private static final String LOGIN_FAILED_LOGIN_COUNT = >> "login.failed-login-count"; >> private static final String LOGIN_FAILED_LOGIN_DATE = >> "login.failed-login-date"; >> >> private static final String LOGIN_FIRST_LOGIN_DATE = >> "login.first-login-date"; >> private static final String LOGIN_RECENT_LOGIN_DATE = >> "login.recent-login-date"; >> >> private static final String ONE = "1"; >> private static final String ZERO = "0"; >> >> private static final LoginStatsRecordingRequiredActionProvider INSTANCE = >> new LoginStatsRecordingRequiredActionProvider(); >> >> @Override >> public void close() { >> // NOOP >> } >> >> @Override >> public void evaluateTriggers(RequiredActionContext context) { >> >> UserModel user = context.getUser(); >> >> try { >> recordFirstLogin(user); >> } catch (Exception ex) { >> LOG.warnv(ex, "Couldn't record first login <{0}>", this); >> } >> >> try { >> recordRecentLogin(user); >> } catch (Exception ex) { >> LOG.warnv(ex, "Couldn't record recent login <{0}>", this); >> } >> >> try { >> recordLoginCount(user); >> } catch (Exception ex) { >> LOG.warnv(ex, "Couldn't record login count <{0}>", this); >> } >> >> try { >> recordFailedLogin(user, context); >> } catch (Exception ex) { >> LOG.warnv(ex, "Couldn't record failed login <{0}>", this); >> } >> } >> >> private void recordFailedLogin(UserModel user, RequiredActionContext >> context) { >> >> UserLoginFailureModel loginFailures = context.getSession().sessions() >> .getUserLoginFailure(context.getRealm(), user.getUsername()); >> >> if (loginFailures != null) { >> user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, >> Arrays.asList(String.valueOf(loginFailures.getNumFailures()))); >> user.setAttribute(LOGIN_FAILED_LOGIN_DATE, >> >> Arrays.asList(getLocalDateTimeFromTimestamp(loginFailures.getLastFailure()).toString())); >> } else { >> user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, Arrays.asList(ZERO)); >> } >> } >> >> private void recordLoginCount(UserModel user) { >> >> List list = user.getAttribute(LOGIN_LOGIN_COUNT); >> >> if (list == null || list.isEmpty()) { >> list = asList(ONE); >> } else { >> list = asList(String.valueOf(Long.parseLong(list.get(0)) + 1)); >> } >> >> user.setAttribute(LOGIN_LOGIN_COUNT, list); >> } >> >> private void recordRecentLogin(UserModel user) { >> user.setAttribute(LOGIN_RECENT_LOGIN_DATE, >> >> asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); >> } >> >> private void recordFirstLogin(UserModel user) { >> >> List list = user.getAttribute(LOGIN_FIRST_LOGIN_DATE); >> >> if (list == null || list.isEmpty()) { >> user.setAttribute(LOGIN_FIRST_LOGIN_DATE, >> >> asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); >> } >> } >> >> @Override >> public void requiredActionChallenge(RequiredActionContext context) { >> // NOOP >> } >> >> @Override >> public void processAction(RequiredActionContext context) { >> context.success(); >> } >> >> @Override >> public RequiredActionProvider create(KeycloakSession session) { >> return INSTANCE; >> } >> >> @Override >> public void init(Scope config) { >> LOG.infov("Creating IdM Keycloak extension <{0}>", this); >> // NOOP >> } >> >> @Override >> public void postInit(KeycloakSessionFactory factory) { >> // NOOP >> } >> >> @Override >> public String getId() { >> return PROVIDER_ID; >> } >> >> @Override >> public String getDisplayText() { >> return RECORD_LOGIN_STATISTICS_ACTION; >> } >> >> private LocalDateTime getLocalDateTimeFromTimestamp(long timestampMillis) >> { >> return LocalDateTime.ofInstant(Instant.ofEpochSecond(timestampMillis / >> 1000), TimeZone.getDefault().toZoneId()); >> } >> } >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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/20160711/1c2cd62a/attachment-0001.html From sthorger at redhat.com Mon Jul 11 02:22:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 11 Jul 2016 08:22:23 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <577F9794.6060904@redhat.com> References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> <5776C857.2070703@redhat.com> <577E08A0.4010409@redhat.com> <577F9794.6060904@redhat.com> Message-ID: On 8 July 2016 at 14:07, Marek Posolda wrote: > On 07/07/16 12:07, Stian Thorgersen wrote: > > > > On 7 July 2016 at 09:45, Marek Posolda wrote: > >> On 04/07/16 09:47, Stian Thorgersen wrote: >> >> ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure >> how it would look like to an end-user. >> >> * Are these managed on a separate screen or on the protocol mappers >> screen? >> >> I am thinking about the protocolMappers screen. Just add another "type" >> of protocolMapper. This means that we don't need to add another >> concept/modelType just for scope parameter, but still we can easily >> filter/view the available mappers of type 'scope aggregator' (on the screen >> with list of all protocolMappers). >> > > Not quite sure I see why it should be on the protocol mappers screen. As > it's a separate type of mapper as well the UI to define them would be > different I'm not sure I see why it can't be a separate screen. > > I think it would fit better on the scope tab. It could have two tabs > "Default scope" and "Scopes" or something like that. > > Not sure which place is better. However I am maybe slightly more for > protocolMappers screen because: > > - It just looks a bit more intuitive to me if all the things, which are > represented at model/DB level by protocolMapper entity are also in admin > console grouped together on single place. But maybe it's just me ;-) > > > - For the aggregated mapper, you can select that "children" mappers will > be either simple mappers or other aggregated mappers. For example for the > "full-profile" mapper, you can select that it's child is another aggregated > mapper "profile" together with some additional simple mappers like > "first_name" or "last_name" . Hence in the list of available mappers, you > should be able to see both simple and aggregated mappers. > Isn't it then a bit confusing that you will see both the simple mappers > like "firstName" (which are configured in "mappers" tab) together with > aggregated mappers like "profile" (which are configured under > "scope/default scope" tab) together? > You lost me a bit here. I think I may have miss understood something you explained before. My assumption was that there are two separate things: regular mappers and scope mappers. Regular mappers are configured as before, while scope mappers are configured for each scope. So there would be separate screens in either case. Maybe I'm wrong here, but I could see a page that lists all scopes, then you can click on the scope to see what mappers are applied as well as what roles are applied. Maybe it's time to do some mock screens or wire frames? > > > Btv. Our current providerModel classes usually have something like: > > Map config; > > on them. However for the aggregated mapper impl, it may be needed to > extend this to: > > Map> config; > > as mapper will need to have the property with the list of children mappers > and property with the list of children roles. The question is, how to > represent it in DB? I can see possibilities like: > a) The value at DB level will be just simple string with children values > divided by some delimiter (eg. "mapper123###mapper456###mapper789" ) > b) The value will be list at DB level with separate record for every value > (eg. 3 values like "mapper123" , "mapper456" , "mapper789" ) > > It seems the (b) is a bit harder for migration, but likely the more proper > way to address this? It looks like something to keep in mind once we > refactor to the "unified" providerModel table. > > > >> >> * How do users define and view scopes, including viewing what >> claims/mappers/roles are associated with a scope? >> * How does a user add/remove claims, protocol mappers and roles to >> a ScopeAggregatorProtocolMapper? >> >> I am thinking that for roles, you will select the roles in same way, like >> it's in current "Scopes" tab of client (or "role mappings" tab of user). >> Probably very similar UI can be used for selecting "children" mappers of >> current protocolMapper though? Something like "Available mappers" and >> "Assigned mappers" and buttons like "Add selected" and "Remove selected". >> Also similarly like for roles, you can view in "Effective mappers" the list >> of all effective mappers in case that you have more composed aggregated >> scopeAggregatorMappers. >> >> For example, if you have mapper for scope parameter "full-profile", which >> will have children mappers, that will point to other scope aggregated >> mappers : "profile" , "email" and "phone". Hence in "Effective mappers" for >> "full-profile" you will see all the descendants, not just the direct >> children. So you will see also all the simple attribute mappers like >> "firstName", "lastName", "birthday", "phone number", ... >> > > Sounds good > > >> >> * Do we provide one or more built-in ScopeAggregatorProtocolMapper that >> are configurable? I assume so and that users don't have to programatically >> define scopes. >> >> Yes. I think that we should provide those built-in, which are specified >> by OIDC specification. Which is "profile" , "email" , "phone" , "address". >> And we will need to define mappers for all their simple attributes ( >> "birthday", "gender" , ...) . Those simple mappers like "birthday" won't be >> root mappers by default, so they won't be applied unless the scope >> parameter is used (for their parent scopeAggregatorMapper). >> >> For backwards compatibility, we will still use the same 'simple' mappers >> like now ( username, email, full name, family name, given name) and they >> will be added to token by default. The scopeAggregator mappers (and their >> corresponding children) will be applied just if the scope parameter with >> corresponding value will be used. >> > > SAML doesn't have this concept does it? If so it probably doesn't even > make sense to show scope mappers for SAML clients. > > I don't think that SAML has something like scope parameter. At least I am > not aware of that :-) > > However our SAML clients currently have "Scope" tab visible to map which > realm roles (or client roles) are allowed to be put into SAML assertion. > That works same like for OIDC clients and makes sense to keep. I guess you > meant to hide just the new sub-tab of the "Scope" tab for configure scope > parameter? > > Marek > > > >> >> > >> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper? >> >> Yes (see above) >> >> Marek >> >> >> On 1 July 2016 at 21:45, Marek Posolda < >> mposolda at redhat.com> wrote: >> >>> Ok, I wasn't also 100% keen about using role. >>> >>> Thinking also about what Pedro mentioned before about protocol mappers. >>> So I wonder that instead of introduce new "scope" concept, we just reuse >>> protocolMappers SPI and have special impl of protocolMapper, which is able >>> to deal with scope parameter and aggregate other "children" protocolMappers >>> and roles? >>> >>> Something like this: >>> - There will be new ProtocolMapper implementation like >>> ScopeAggregatorProtocolMapper. You will define value of scope parameter >>> (eg. "photo" ) in the configuration of this protocolMapper. Mapper will be >>> ignored if scope parameter value with this name was not used. >>> >>> - You will be able to define "children" protocolMappers and "children" >>> roles in ScopeAggregatorProtocolMapper. >>> >>> - For each client (and clientTemplate), we will have many defined >>> protocolMappers, but just some subset of them are "root" mappers, which are >>> applied by default. The rest of mappers will be used just as "children" of >>> root mappers. So in client model, we might have: >>> client.getDefinedProtocolMappers() // all defined >>> client.getProtocolMappers() // just subset of defined (defacto root >>> mappers) >>> >>> - For example: client will have defined protocolMappers: firstName, >>> lastName, birthday, profile, email. Just "profile" and "email" will be root >>> mappers. And "profile" is ScopeAggregatorMapper for scope value "profile" >>> and it's children mappers are : firstName, lastName, birthday. >>> >>> So then: >>> -- user will send "scope=profile" . Then defacto all of "firstName", >>> "lastName", "birthday", "email" claims will be included in token. On >>> consent screen will be just "Profile" and "Email" >>> -- user won't send "scope=profile" . Then defacto just "email" claim >>> will be included (So for this example, email is always included even if not >>> specified by scope parameter). >>> >>> - With this concept, we are able to aggregate many various claims into >>> single value of "scope" and on the consent screen have just the roots. This >>> would fit well for the default scope values mentioned by OIDC specs. We are >>> also able to define mappers (claims), which will be always available even >>> if not specified by scope parameter. >>> >>> - For the roles, I am not 100% sure whether to include them into the >>> concept or not? However it seems to me that rather yes. The particular role >>> will be applied into token just if all of those 3 conditions are met: >>> 1) user is member of the role >>> 2) client has scope for the role (so current "scope" tab in clients will >>> remain as is) >>> 3) if role has scopePAramRequired=true, then it must be included in some >>> mapper (in other words, those roles are not included directly in >>> clientSession.getRoles , but it's the responsibility of >>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are >>> met). >>> >>> So again, user won't see all children roles on consent screen. Just the >>> parent protocolMapper. >>> >>> This will work fine with "scope=offline_access" . There will be >>> protocolMapper for "offline_access" parameter, which will aggregate just >>> one children role (the current realm role "offline_access"). The offline >>> token will be issued just if accessToken will have "offline_access" >>> permission. So if some client, doesn't need offline tokens, it can just >>> remove "offline_access" protocolMapper. Also if some user shouldn't be >>> allowed to request offline tokens, admin can remove him from the >>> "offline_access" role. >>> >>> - If some scope parameter is applicable for more clients, it can be >>> defined on clientTemplate. >>> >>> >>> PS: I will be on holidays and back on next Thursday 7th July. So sorry >>> if I won't reply immediately to next mails. >>> >>> Mare >>> >>> >>> >>> On 01/07/16 14:57, Pedro Igor Silva wrote: >>> >>>> Reading all of this makes me think it would be cleaner to introduce a >>>>> separate scope concept ;) >>>>> >>>>> A user doesn't have a scope - a user has roles and attributes. >>>>> Re-using roles >>>>> concept for the scope just makes it feel awkward and retrofitted. >>>>> >>>> +10000 >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160711/b680c2b4/attachment-0001.html From sthorger at redhat.com Mon Jul 11 02:25:39 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 11 Jul 2016 08:25:39 +0200 Subject: [keycloak-dev] Disabling error notification in admin console In-Reply-To: <1468172775.31604.7.camel@cargosoft.ru> References: <1468172775.31604.7.camel@cargosoft.ru> Message-ID: Maybe you can replace the notification service with your own implementation. On 10 July 2016 at 19:46, Mitya wrote: > Hi, > > By default, if admin console receives a HTTP 500 from any underlying REST > resource, it will pop up a small notification (implemented by > errorInterceptor, app.js:1775). > > I'm developing a KeyCloak extension that includes a custom REST resource > and adds GUI elements to admin console. Instead of standard notification, > I'd like to pop up a modal dialog with verbose error description received > from the server. Everything works fine (with $modal.open), but that default > notification lingers behind my dialog. I know it's a purely cosmetic issue, > but still a bit annoying. Is there any way to get rid of that notification > in case modal dialog is used? > > Thx, > Mitya > > > _______________________________________________ > 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/20160711/965ae161/attachment.html From mposolda at redhat.com Mon Jul 11 03:35:04 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 11 Jul 2016 09:35:04 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> <5776C857.2070703@redhat.com> <577E08A0.4010409@redhat.com> <577F9794.6060904@redhat.com> Message-ID: <57834C28.7090309@redhat.com> On 11/07/16 08:22, Stian Thorgersen wrote: > > > On 8 July 2016 at 14:07, Marek Posolda > wrote: > > On 07/07/16 12:07, Stian Thorgersen wrote: >> >> >> On 7 July 2016 at 09:45, Marek Posolda > > wrote: >> >> On 04/07/16 09:47, Stian Thorgersen wrote: >>> ScopeAggregatorProtocolMapper sounds interesting, but I'm >>> not quite sure how it would look like to an end-user. >>> >>> * Are these managed on a separate screen or on the protocol >>> mappers screen? >> I am thinking about the protocolMappers screen. Just add >> another "type" of protocolMapper. This means that we don't >> need to add another concept/modelType just for scope >> parameter, but still we can easily filter/view the available >> mappers of type 'scope aggregator' (on the screen with list >> of all protocolMappers). >> >> >> Not quite sure I see why it should be on the protocol mappers >> screen. As it's a separate type of mapper as well the UI to >> define them would be different I'm not sure I see why it can't be >> a separate screen. >> >> I think it would fit better on the scope tab. It could have two >> tabs "Default scope" and "Scopes" or something like that. > Not sure which place is better. However I am maybe slightly more > for protocolMappers screen because: > > - It just looks a bit more intuitive to me if all the things, > which are represented at model/DB level by protocolMapper entity > are also in admin console grouped together on single place. But > maybe it's just me ;-) > > > > - For the aggregated mapper, you can select that "children" > mappers will be either simple mappers or other aggregated mappers. > For example for the "full-profile" mapper, you can select that > it's child is another aggregated mapper "profile" together with > some additional simple mappers like "first_name" or "last_name" . > Hence in the list of available mappers, you should be able to see > both simple and aggregated mappers. > Isn't it then a bit confusing that you will see both the simple > mappers like "firstName" (which are configured in "mappers" tab) > together with aggregated mappers like "profile" (which are > configured under "scope/default scope" tab) together? > > > You lost me a bit here. I think I may have miss understood something > you explained before. > > My assumption was that there are two separate things: regular mappers > and scope mappers. Regular mappers are configured as before, while > scope mappers are configured for each scope. So there would be > separate screens in either case. Maybe I'm wrong here, but I could see > a page that lists all scopes, then you can click on the scope to see > what mappers are applied as well as what roles are applied. I was thinking about ScopeAggregatedMapper just like about another implementation of ProtocolMapper interface. No another special model or special mapper type, which Keycloak needs to deal with. The Keycloak (TokenManager) will treat like any other mapper, so will just call "transformAccessToken" to it and ScopeAggregatedMapper impl will delegate to other children mappers and apply roles. The difference is, that UI will need to be a bit special then for other mappers. There is possibility that we will add the support showing list of roles and protocolMappers to the directive "kc-provider-config" . However it looks the better option might be that particular protocolMapper implementation (or particular provider implementation in general) has a way to override the angular template with it's own UI if it wants to do it. For example, if there is protocolMapper provider with id "foo" then angular will: - First look if there is special screen "protocol-mapper-detail_foo.html" . - If the screen doesn't exist, it will fallback to default "protocol-mapper-detail.html" screen with the "kc-provider-config" directive for generic properties. For the protocolMapper, the scopeAggregatedMapper will have special screen "protocol-mapper-detail_scope-aggregate.html" when all other impls just use the generic screen like now. > > Maybe it's time to do some mock screens or wire frames? +1 or start prototyping and see how it goes? :) Marek > > > > Btv. Our current providerModel classes usually have something like: > > Map config; > > on them. However for the aggregated mapper impl, it may be needed > to extend this to: > > Map> config; > > as mapper will need to have the property with the list of children > mappers and property with the list of children roles. The question > is, how to represent it in DB? I can see possibilities like: > a) The value at DB level will be just simple string with children > values divided by some delimiter (eg. > "mapper123###mapper456###mapper789" ) > b) The value will be list at DB level with separate record for > every value (eg. 3 values like "mapper123" , "mapper456" , > "mapper789" ) > > It seems the (b) is a bit harder for migration, but likely the > more proper way to address this? It looks like something to keep > in mind once we refactor to the "unified" providerModel table. > >> >>> * How do users define and view scopes, including viewing >>> what claims/mappers/roles are associated with a scope? >>> * How does a user add/remove claims, protocol mappers and >>> roles to a ScopeAggregatorProtocolMapper? >> I am thinking that for roles, you will select the roles in >> same way, like it's in current "Scopes" tab of client (or >> "role mappings" tab of user). Probably very similar UI can be >> used for selecting "children" mappers of current >> protocolMapper though? Something like "Available mappers" and >> "Assigned mappers" and buttons like "Add selected" and >> "Remove selected". Also similarly like for roles, you can >> view in "Effective mappers" the list of all effective mappers >> in case that you have more composed aggregated >> scopeAggregatorMappers. >> >> For example, if you have mapper for scope parameter >> "full-profile", which will have children mappers, that will >> point to other scope aggregated mappers : "profile" , "email" >> and "phone". Hence in "Effective mappers" for "full-profile" >> you will see all the descendants, not just the direct >> children. So you will see also all the simple attribute >> mappers like "firstName", "lastName", "birthday", "phone >> number", ... >> >> >> Sounds good >> >> >>> * Do we provide one or more built-in >>> ScopeAggregatorProtocolMapper that are configurable? I >>> assume so and that users don't have to programatically >>> define scopes. >> Yes. I think that we should provide those built-in, which are >> specified by OIDC specification. Which is "profile" , "email" >> , "phone" , "address". And we will need to define mappers for >> all their simple attributes ( "birthday", "gender" , ...) . >> Those simple mappers like "birthday" won't be root mappers by >> default, so they won't be applied unless the scope parameter >> is used (for their parent scopeAggregatorMapper). >> >> For backwards compatibility, we will still use the same >> 'simple' mappers like now ( username, email, full name, >> family name, given name) and they will be added to token by >> default. The scopeAggregator mappers (and their corresponding >> children) will be applied just if the scope parameter with >> corresponding value will be used. >> >> >> SAML doesn't have this concept does it? If so it probably doesn't >> even make sense to show scope mappers for SAML clients. > I don't think that SAML has something like scope parameter. At > least I am not aware of that :-) > > However our SAML clients currently have "Scope" tab visible to map > which realm roles (or client roles) are allowed to be put into > SAML assertion. That works same like for OIDC clients and makes > sense to keep. I guess you meant to hide just the new sub-tab of > the "Scope" tab for configure scope parameter? > > Marek > >> >>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper? >> Yes (see above) >> >> Marek >> >>> >>> On 1 July 2016 at 21:45, Marek Posolda >> > wrote: >>> >>> Ok, I wasn't also 100% keen about using role. >>> >>> Thinking also about what Pedro mentioned before about >>> protocol mappers. So I wonder that instead of introduce >>> new "scope" concept, we just reuse protocolMappers SPI >>> and have special impl of protocolMapper, which is able >>> to deal with scope parameter and aggregate other >>> "children" protocolMappers and roles? >>> >>> Something like this: >>> - There will be new ProtocolMapper implementation like >>> ScopeAggregatorProtocolMapper. You will define value of >>> scope parameter (eg. "photo" ) in the configuration of >>> this protocolMapper. Mapper will be ignored if scope >>> parameter value with this name was not used. >>> >>> - You will be able to define "children" protocolMappers >>> and "children" roles in ScopeAggregatorProtocolMapper. >>> >>> - For each client (and clientTemplate), we will have >>> many defined protocolMappers, but just some subset of >>> them are "root" mappers, which are applied by default. >>> The rest of mappers will be used just as "children" of >>> root mappers. So in client model, we might have: >>> client.getDefinedProtocolMappers() // all defined >>> client.getProtocolMappers() // just subset of defined >>> (defacto root mappers) >>> >>> - For example: client will have defined protocolMappers: >>> firstName, lastName, birthday, profile, email. Just >>> "profile" and "email" will be root mappers. And >>> "profile" is ScopeAggregatorMapper for scope value >>> "profile" and it's children mappers are : firstName, >>> lastName, birthday. >>> >>> So then: >>> -- user will send "scope=profile" . Then defacto all of >>> "firstName", "lastName", "birthday", "email" claims will >>> be included in token. On consent screen will be just >>> "Profile" and "Email" >>> -- user won't send "scope=profile" . Then defacto just >>> "email" claim will be included (So for this example, >>> email is always included even if not specified by scope >>> parameter). >>> >>> - With this concept, we are able to aggregate many >>> various claims into single value of "scope" and on the >>> consent screen have just the roots. This would fit well >>> for the default scope values mentioned by OIDC specs. We >>> are also able to define mappers (claims), which will be >>> always available even if not specified by scope parameter. >>> >>> - For the roles, I am not 100% sure whether to include >>> them into the concept or not? However it seems to me >>> that rather yes. The particular role will be applied >>> into token just if all of those 3 conditions are met: >>> 1) user is member of the role >>> 2) client has scope for the role (so current "scope" tab >>> in clients will remain as is) >>> 3) if role has scopePAramRequired=true, then it must be >>> included in some mapper (in other words, those roles are >>> not included directly in clientSession.getRoles , but >>> it's the responsibility of ScopeAggregatorProtocolMapper >>> to add them into token if conditions 1+2 are met). >>> >>> So again, user won't see all children roles on consent >>> screen. Just the parent protocolMapper. >>> >>> This will work fine with "scope=offline_access" . There >>> will be protocolMapper for "offline_access" parameter, >>> which will aggregate just one children role (the current >>> realm role "offline_access"). The offline token will be >>> issued just if accessToken will have "offline_access" >>> permission. So if some client, doesn't need offline >>> tokens, it can just remove "offline_access" >>> protocolMapper. Also if some user shouldn't be allowed >>> to request offline tokens, admin can remove him from the >>> "offline_access" role. >>> >>> - If some scope parameter is applicable for more >>> clients, it can be defined on clientTemplate. >>> >>> >>> PS: I will be on holidays and back on next Thursday 7th >>> July. So sorry if I won't reply immediately to next mails. >>> >>> Mare >>> >>> >>> >>> On 01/07/16 14:57, Pedro Igor Silva wrote: >>> >>> Reading all of this makes me think it would be >>> cleaner to introduce a >>> separate scope concept ;) >>> >>> A user doesn't have a scope - a user has roles >>> and attributes. Re-using roles >>> concept for the scope just makes it feel awkward >>> and retrofitted. >>> >>> +10000 >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160711/ded51fc5/attachment-0001.html From thomas.darimont at googlemail.com Mon Jul 11 04:22:14 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 11 Jul 2016 10:22:14 +0200 Subject: [keycloak-dev] Community curated Keycloak Extensions Repository Message-ID: Hello Group, I was wondering whether it would make sense have some kind of community backed keycloak-extensions organisation on github in order to collect various extensions to Keycloak. This organisation could contain repositories with community curated extensions that would be independently released from keycloak with installation descriptions with JBoss CLI scripts for installing them. For instance: - FederationProviders - EventListeners - Authenticators - RequiredActions - Themes - Docker Containers Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160711/a5604884/attachment.html From thomas.darimont at googlemail.com Mon Jul 11 04:28:02 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 11 Jul 2016 10:28:02 +0200 Subject: [keycloak-dev] TokenEndpoint is potentially too restrictive In-Reply-To: References: <577F90FF.6050006@redhat.com> Message-ID: Hi, an EventListener would work as well - but in this case RequiredAction was IMHO simpler than a custom EventListener (less ceremony). Besides the configuration gotcha discussed above, do you see any advantage of using an EventListener here instead of an RequiredAction? Cheers, Thomas 2016-07-11 8:08 GMT+02:00 Stian Thorgersen : > Would it not be better to use an event listener for this? > > On 8 July 2016 at 14:13, Thomas Darimont > wrote: > >> Thanks Marek, that makes sense now. >> >> Removing the "default" checkbox on my provider did the trick - yes I want >> to execute this action for every user regardless on login in the sense of >> an filter / interceptor. >> >> Btw. this use case I implemented is IMHO quite common - would be cool if >> keycloak would ship with something like that out-of-the-box ;-) >> >> Cheers, >> Thomas >> >> 2016-07-08 13:39 GMT+02:00 Marek Posolda : >> >>> There was already some quite a long discussion about similar stuff. It >>> was about consents though, not about required actions. However IMO both >>> consents and requiredActions are quite similar thing and it's by design >>> that user is not able to login with directGrant if he has either consent or >>> requiredAction on himself. >>> >>> However when I look at your particular use-case, it seems that you are >>> using LoginStatsRecordingRequiredActionProvider as an interceptor, which >>> doesn't need any real requiredAction on user, but you just want to ensure >>> that "evaluateTriggers" is called after each user login. Is it correct? >>> >>> Then you can just check your requiredAction provider as "enabled", but >>> NOT as "default" . Note that "evaluateTriggers" will be always invoked for >>> every user after his login even if user doesn't have the particular action >>> on him. The purpose of "evaluateTriggers" is actually to check, if >>> requiredAction should be added to the user if some specific conditions >>> occurs. For example see VerifyEmail.evaluateTriggers , which adds the >>> VERIFY_EMAIL requiredAction to user if he doesn't yet have verified email. >>> >>> Marek >>> >>> >>> On 08/07/16 10:35, Thomas Darimont wrote: >>> >>> Hello Group, >>> >>> I just found out that as long as a user has a required_action set up one >>> cannot authenticate via grant_type password throught the TokenEndpoint >>> because of this line in >>> TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant >>> >>> if (user.getRequiredActions() != null && >>> user.getRequiredActions().size() > 0) { >>> event.error(Errors.RESOLVE_REQUIRED_ACTIONS); >>> throw new ErrorResponseException("invalid_grant", "Account is not >>> fully set up", Response.Status.BAD_REQUEST); >>> } >>> >>> current master: >>> >>> https://github.com/keycloak/keycloak/blob/bd2887aa77184d82e795e4200eb55a3d9b11e4d4/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 >>> >>> 1.9.x >>> >>> https://github.com/keycloak/keycloak/blob/e7822431fded5948a5e248766e6ffbf86d476cf8/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 >>> >>> I think that this is too restrictive. Imagine a default required action >>> that has no user interaction but records some user login statistics like >>> last login date, count logins, login failures etc. >>> In this case it would be better to check if the configured >>> required_action requires user-interaction (e.g. via a new method boolean >>> isInteractive()) >>> or communicate that required actions should not be used for actions that >>> don't require user interactions - an authenticator is then probably the >>> better choice. >>> >>> Cheers, >>> Thomas >>> >>> I tested this with a required action like the >>> LoginStatsRecordingRequiredActionProvider listed below. >>> Now setup a client with the name test-client and a user with the name >>> tester. >>> >>> With that deployed to keycloak as a default action one can use the >>> following curl command >>> to see the problem. >>> >>> KC_REALM=test-realm >>> KC_USERNAME=tester >>> KC_PASSWORD=test >>> KC_CLIENT=test-client >>> KC_CLIENT_SECRET=e9ca8fad-d399-4455-5290-817102e7f9ff >>> KC_SERVER=192.168.99.1:8080 >>> KC_CONTEXT=auth >>> >>> curl -k -v --noproxy 192.168.99.1 \ >>> -H "Content-Type: application/x-www-form-urlencoded" \ >>> -d "grant_type=password" \ >>> -d "username=$KC_USERNAME" \ >>> -d "password=$KC_PASSWORD" \ >>> -d "client_id=$KC_CLIENT" \ >>> -d "client_secret=$KC_CLIENT_SECRET" \ >>> >>> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" >>> >>> >>> Gives: >>> < HTTP/1.1 400 Bad Request >>> < Connection: keep-alive >>> < X-Powered-By: Undertow/1 >>> < Server: WildFly/10 >>> < Content-Type: application/json >>> < Content-Length: 75 >>> < Date: Fri, 08 Jul 2016 08:24:59 GMT >>> {"error_description":"Account is not fully set >>> up","error":"invalid_grant"} >>> >>> >>> ---- >>> >>> >>> package com.acme.keycloak.ext.authentication; >>> >>> import static java.util.Arrays.asList; >>> >>> import java.time.Instant; >>> import java.time.LocalDateTime; >>> import java.util.Arrays; >>> import java.util.List; >>> import java.util.TimeZone; >>> >>> import org.jboss.logging.Logger; >>> import org.keycloak.Config.Scope; >>> import org.keycloak.authentication.RequiredActionContext; >>> import org.keycloak.authentication.RequiredActionFactory; >>> import org.keycloak.authentication.RequiredActionProvider; >>> import org.keycloak.models.KeycloakSession; >>> import org.keycloak.models.KeycloakSessionFactory; >>> import org.keycloak.models.UserLoginFailureModel; >>> import org.keycloak.models.UserModel; >>> >>> /** >>> * Collects information about User Login behaviour. >>> *

>>> * Collects the following: >>> *

    >>> *
  • Date / Time of first login
    • >>> *
  • Date / Time of recent login
    • >>> *
  • Count of logins since first login
    • >>> *
  • Count of failed logins since the configured Failure Reset >>> Time unter Security Defenses
    • >>> *
>>> *

>>> * This {@link RequiredActionProvider} is Stateless and can be reused. >>> * >>> * @author tdarimont >>> */ >>> public class LoginStatsRecordingRequiredActionProvider implements >>> RequiredActionProvider, RequiredActionFactory { >>> >>> private static final Logger LOG = >>> Logger.getLogger(LoginStatsRecordingRequiredActionProvider.class); >>> >>> private static final String PROVIDER_ID = "login_stats_action"; >>> private static final String RECORD_LOGIN_STATISTICS_ACTION = "Record >>> Login Statistics Action"; >>> >>> private static final String LOGIN_LOGIN_COUNT = "login.login-count"; >>> private static final String LOGIN_FAILED_LOGIN_COUNT = >>> "login.failed-login-count"; >>> private static final String LOGIN_FAILED_LOGIN_DATE = >>> "login.failed-login-date"; >>> >>> private static final String LOGIN_FIRST_LOGIN_DATE = >>> "login.first-login-date"; >>> private static final String LOGIN_RECENT_LOGIN_DATE = >>> "login.recent-login-date"; >>> >>> private static final String ONE = "1"; >>> private static final String ZERO = "0"; >>> >>> private static final LoginStatsRecordingRequiredActionProvider INSTANCE >>> = new LoginStatsRecordingRequiredActionProvider(); >>> >>> @Override >>> public void close() { >>> // NOOP >>> } >>> >>> @Override >>> public void evaluateTriggers(RequiredActionContext context) { >>> >>> UserModel user = context.getUser(); >>> >>> try { >>> recordFirstLogin(user); >>> } catch (Exception ex) { >>> LOG.warnv(ex, "Couldn't record first login <{0}>", this); >>> } >>> >>> try { >>> recordRecentLogin(user); >>> } catch (Exception ex) { >>> LOG.warnv(ex, "Couldn't record recent login <{0}>", this); >>> } >>> >>> try { >>> recordLoginCount(user); >>> } catch (Exception ex) { >>> LOG.warnv(ex, "Couldn't record login count <{0}>", this); >>> } >>> >>> try { >>> recordFailedLogin(user, context); >>> } catch (Exception ex) { >>> LOG.warnv(ex, "Couldn't record failed login <{0}>", this); >>> } >>> } >>> >>> private void recordFailedLogin(UserModel user, RequiredActionContext >>> context) { >>> >>> UserLoginFailureModel loginFailures = context.getSession().sessions() >>> .getUserLoginFailure(context.getRealm(), user.getUsername()); >>> >>> if (loginFailures != null) { >>> user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, >>> Arrays.asList(String.valueOf(loginFailures.getNumFailures()))); >>> user.setAttribute(LOGIN_FAILED_LOGIN_DATE, >>> >>> Arrays.asList(getLocalDateTimeFromTimestamp(loginFailures.getLastFailure()).toString())); >>> } else { >>> user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, Arrays.asList(ZERO)); >>> } >>> } >>> >>> private void recordLoginCount(UserModel user) { >>> >>> List list = user.getAttribute(LOGIN_LOGIN_COUNT); >>> >>> if (list == null || list.isEmpty()) { >>> list = asList(ONE); >>> } else { >>> list = asList(String.valueOf(Long.parseLong(list.get(0)) + 1)); >>> } >>> >>> user.setAttribute(LOGIN_LOGIN_COUNT, list); >>> } >>> >>> private void recordRecentLogin(UserModel user) { >>> user.setAttribute(LOGIN_RECENT_LOGIN_DATE, >>> >>> asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); >>> } >>> >>> private void recordFirstLogin(UserModel user) { >>> >>> List list = user.getAttribute(LOGIN_FIRST_LOGIN_DATE); >>> >>> if (list == null || list.isEmpty()) { >>> user.setAttribute(LOGIN_FIRST_LOGIN_DATE, >>> >>> asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); >>> } >>> } >>> >>> @Override >>> public void requiredActionChallenge(RequiredActionContext context) { >>> // NOOP >>> } >>> >>> @Override >>> public void processAction(RequiredActionContext context) { >>> context.success(); >>> } >>> >>> @Override >>> public RequiredActionProvider create(KeycloakSession session) { >>> return INSTANCE; >>> } >>> >>> @Override >>> public void init(Scope config) { >>> LOG.infov("Creating IdM Keycloak extension <{0}>", this); >>> // NOOP >>> } >>> >>> @Override >>> public void postInit(KeycloakSessionFactory factory) { >>> // NOOP >>> } >>> >>> @Override >>> public String getId() { >>> return PROVIDER_ID; >>> } >>> >>> @Override >>> public String getDisplayText() { >>> return RECORD_LOGIN_STATISTICS_ACTION; >>> } >>> >>> private LocalDateTime getLocalDateTimeFromTimestamp(long >>> timestampMillis) { >>> return LocalDateTime.ofInstant(Instant.ofEpochSecond(timestampMillis / >>> 1000), TimeZone.getDefault().toZoneId()); >>> } >>> } >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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/20160711/68b3eb6b/attachment-0001.html From sthorger at redhat.com Mon Jul 11 06:10:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 11 Jul 2016 12:10:11 +0200 Subject: [keycloak-dev] TokenEndpoint is potentially too restrictive In-Reply-To: References: <577F90FF.6050006@redhat.com> Message-ID: A required action is aimed at an action a user has to take, not as a way to listen for events. So you'd end up with a null-op action just so that you can log an event. On 11 July 2016 at 10:28, Thomas Darimont wrote: > Hi, > > an EventListener would work as well - but in this case RequiredAction was > IMHO simpler than a custom EventListener (less ceremony). > Besides the configuration gotcha discussed above, do you see any advantage > of using an EventListener here instead of an RequiredAction? > > Cheers, > Thomas > > 2016-07-11 8:08 GMT+02:00 Stian Thorgersen : > >> Would it not be better to use an event listener for this? >> >> On 8 July 2016 at 14:13, Thomas Darimont >> wrote: >> >>> Thanks Marek, that makes sense now. >>> >>> Removing the "default" checkbox on my provider did the trick - yes I >>> want to execute this action for every user regardless on login in the sense >>> of an filter / interceptor. >>> >>> Btw. this use case I implemented is IMHO quite common - would be cool if >>> keycloak would ship with something like that out-of-the-box ;-) >>> >>> Cheers, >>> Thomas >>> >>> 2016-07-08 13:39 GMT+02:00 Marek Posolda : >>> >>>> There was already some quite a long discussion about similar stuff. It >>>> was about consents though, not about required actions. However IMO both >>>> consents and requiredActions are quite similar thing and it's by design >>>> that user is not able to login with directGrant if he has either consent or >>>> requiredAction on himself. >>>> >>>> However when I look at your particular use-case, it seems that you are >>>> using LoginStatsRecordingRequiredActionProvider as an interceptor, which >>>> doesn't need any real requiredAction on user, but you just want to ensure >>>> that "evaluateTriggers" is called after each user login. Is it correct? >>>> >>>> Then you can just check your requiredAction provider as "enabled", but >>>> NOT as "default" . Note that "evaluateTriggers" will be always invoked for >>>> every user after his login even if user doesn't have the particular action >>>> on him. The purpose of "evaluateTriggers" is actually to check, if >>>> requiredAction should be added to the user if some specific conditions >>>> occurs. For example see VerifyEmail.evaluateTriggers , which adds the >>>> VERIFY_EMAIL requiredAction to user if he doesn't yet have verified email. >>>> >>>> Marek >>>> >>>> >>>> On 08/07/16 10:35, Thomas Darimont wrote: >>>> >>>> Hello Group, >>>> >>>> I just found out that as long as a user has a required_action set up >>>> one cannot authenticate via grant_type password throught the TokenEndpoint >>>> because of this line in >>>> TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant >>>> >>>> if (user.getRequiredActions() != null && >>>> user.getRequiredActions().size() > 0) { >>>> event.error(Errors.RESOLVE_REQUIRED_ACTIONS); >>>> throw new ErrorResponseException("invalid_grant", "Account is not >>>> fully set up", Response.Status.BAD_REQUEST); >>>> } >>>> >>>> current master: >>>> >>>> https://github.com/keycloak/keycloak/blob/bd2887aa77184d82e795e4200eb55a3d9b11e4d4/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 >>>> >>>> 1.9.x >>>> >>>> https://github.com/keycloak/keycloak/blob/e7822431fded5948a5e248766e6ffbf86d476cf8/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L388 >>>> >>>> I think that this is too restrictive. Imagine a default required action >>>> that has no user interaction but records some user login statistics like >>>> last login date, count logins, login failures etc. >>>> In this case it would be better to check if the configured >>>> required_action requires user-interaction (e.g. via a new method boolean >>>> isInteractive()) >>>> or communicate that required actions should not be used for actions >>>> that don't require user interactions - an authenticator is then probably >>>> the better choice. >>>> >>>> Cheers, >>>> Thomas >>>> >>>> I tested this with a required action like the >>>> LoginStatsRecordingRequiredActionProvider listed below. >>>> Now setup a client with the name test-client and a user with the name >>>> tester. >>>> >>>> With that deployed to keycloak as a default action one can use the >>>> following curl command >>>> to see the problem. >>>> >>>> KC_REALM=test-realm >>>> KC_USERNAME=tester >>>> KC_PASSWORD=test >>>> KC_CLIENT=test-client >>>> KC_CLIENT_SECRET=e9ca8fad-d399-4455-5290-817102e7f9ff >>>> KC_SERVER=192.168.99.1:8080 >>>> KC_CONTEXT=auth >>>> >>>> curl -k -v --noproxy 192.168.99.1 \ >>>> -H "Content-Type: application/x-www-form-urlencoded" \ >>>> -d "grant_type=password" \ >>>> -d "username=$KC_USERNAME" \ >>>> -d "password=$KC_PASSWORD" \ >>>> -d "client_id=$KC_CLIENT" \ >>>> -d "client_secret=$KC_CLIENT_SECRET" \ >>>> >>>> "http://$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" >>>> >>>> >>>> Gives: >>>> < HTTP/1.1 400 Bad Request >>>> < Connection: keep-alive >>>> < X-Powered-By: Undertow/1 >>>> < Server: WildFly/10 >>>> < Content-Type: application/json >>>> < Content-Length: 75 >>>> < Date: Fri, 08 Jul 2016 08:24:59 GMT >>>> {"error_description":"Account is not fully set >>>> up","error":"invalid_grant"} >>>> >>>> >>>> ---- >>>> >>>> >>>> package com.acme.keycloak.ext.authentication; >>>> >>>> import static java.util.Arrays.asList; >>>> >>>> import java.time.Instant; >>>> import java.time.LocalDateTime; >>>> import java.util.Arrays; >>>> import java.util.List; >>>> import java.util.TimeZone; >>>> >>>> import org.jboss.logging.Logger; >>>> import org.keycloak.Config.Scope; >>>> import org.keycloak.authentication.RequiredActionContext; >>>> import org.keycloak.authentication.RequiredActionFactory; >>>> import org.keycloak.authentication.RequiredActionProvider; >>>> import org.keycloak.models.KeycloakSession; >>>> import org.keycloak.models.KeycloakSessionFactory; >>>> import org.keycloak.models.UserLoginFailureModel; >>>> import org.keycloak.models.UserModel; >>>> >>>> /** >>>> * Collects information about User Login behaviour. >>>> *

>>>> * Collects the following: >>>> *

    >>>> *
  • Date / Time of first login
    • >>>> *
  • Date / Time of recent login
    • >>>> *
  • Count of logins since first login
    • >>>> *
  • Count of failed logins since the configured Failure Reset >>>> Time unter Security Defenses
    • >>>> *
>>>> *

>>>> * This {@link RequiredActionProvider} is Stateless and can be reused. >>>> * >>>> * @author tdarimont >>>> */ >>>> public class LoginStatsRecordingRequiredActionProvider implements >>>> RequiredActionProvider, RequiredActionFactory { >>>> >>>> private static final Logger LOG = >>>> Logger.getLogger(LoginStatsRecordingRequiredActionProvider.class); >>>> >>>> private static final String PROVIDER_ID = "login_stats_action"; >>>> private static final String RECORD_LOGIN_STATISTICS_ACTION = "Record >>>> Login Statistics Action"; >>>> >>>> private static final String LOGIN_LOGIN_COUNT = "login.login-count"; >>>> private static final String LOGIN_FAILED_LOGIN_COUNT = >>>> "login.failed-login-count"; >>>> private static final String LOGIN_FAILED_LOGIN_DATE = >>>> "login.failed-login-date"; >>>> >>>> private static final String LOGIN_FIRST_LOGIN_DATE = >>>> "login.first-login-date"; >>>> private static final String LOGIN_RECENT_LOGIN_DATE = >>>> "login.recent-login-date"; >>>> >>>> private static final String ONE = "1"; >>>> private static final String ZERO = "0"; >>>> >>>> private static final LoginStatsRecordingRequiredActionProvider INSTANCE >>>> = new LoginStatsRecordingRequiredActionProvider(); >>>> >>>> @Override >>>> public void close() { >>>> // NOOP >>>> } >>>> >>>> @Override >>>> public void evaluateTriggers(RequiredActionContext context) { >>>> >>>> UserModel user = context.getUser(); >>>> >>>> try { >>>> recordFirstLogin(user); >>>> } catch (Exception ex) { >>>> LOG.warnv(ex, "Couldn't record first login <{0}>", this); >>>> } >>>> >>>> try { >>>> recordRecentLogin(user); >>>> } catch (Exception ex) { >>>> LOG.warnv(ex, "Couldn't record recent login <{0}>", this); >>>> } >>>> >>>> try { >>>> recordLoginCount(user); >>>> } catch (Exception ex) { >>>> LOG.warnv(ex, "Couldn't record login count <{0}>", this); >>>> } >>>> >>>> try { >>>> recordFailedLogin(user, context); >>>> } catch (Exception ex) { >>>> LOG.warnv(ex, "Couldn't record failed login <{0}>", this); >>>> } >>>> } >>>> >>>> private void recordFailedLogin(UserModel user, RequiredActionContext >>>> context) { >>>> >>>> UserLoginFailureModel loginFailures = context.getSession().sessions() >>>> .getUserLoginFailure(context.getRealm(), user.getUsername()); >>>> >>>> if (loginFailures != null) { >>>> user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, >>>> Arrays.asList(String.valueOf(loginFailures.getNumFailures()))); >>>> user.setAttribute(LOGIN_FAILED_LOGIN_DATE, >>>> >>>> Arrays.asList(getLocalDateTimeFromTimestamp(loginFailures.getLastFailure()).toString())); >>>> } else { >>>> user.setAttribute(LOGIN_FAILED_LOGIN_COUNT, Arrays.asList(ZERO)); >>>> } >>>> } >>>> >>>> private void recordLoginCount(UserModel user) { >>>> >>>> List list = user.getAttribute(LOGIN_LOGIN_COUNT); >>>> >>>> if (list == null || list.isEmpty()) { >>>> list = asList(ONE); >>>> } else { >>>> list = asList(String.valueOf(Long.parseLong(list.get(0)) + 1)); >>>> } >>>> >>>> user.setAttribute(LOGIN_LOGIN_COUNT, list); >>>> } >>>> >>>> private void recordRecentLogin(UserModel user) { >>>> user.setAttribute(LOGIN_RECENT_LOGIN_DATE, >>>> >>>> asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); >>>> } >>>> >>>> private void recordFirstLogin(UserModel user) { >>>> >>>> List list = user.getAttribute(LOGIN_FIRST_LOGIN_DATE); >>>> >>>> if (list == null || list.isEmpty()) { >>>> user.setAttribute(LOGIN_FIRST_LOGIN_DATE, >>>> >>>> asList(getLocalDateTimeFromTimestamp(System.currentTimeMillis()).toString())); >>>> } >>>> } >>>> >>>> @Override >>>> public void requiredActionChallenge(RequiredActionContext context) { >>>> // NOOP >>>> } >>>> >>>> @Override >>>> public void processAction(RequiredActionContext context) { >>>> context.success(); >>>> } >>>> >>>> @Override >>>> public RequiredActionProvider create(KeycloakSession session) { >>>> return INSTANCE; >>>> } >>>> >>>> @Override >>>> public void init(Scope config) { >>>> LOG.infov("Creating IdM Keycloak extension <{0}>", this); >>>> // NOOP >>>> } >>>> >>>> @Override >>>> public void postInit(KeycloakSessionFactory factory) { >>>> // NOOP >>>> } >>>> >>>> @Override >>>> public String getId() { >>>> return PROVIDER_ID; >>>> } >>>> >>>> @Override >>>> public String getDisplayText() { >>>> return RECORD_LOGIN_STATISTICS_ACTION; >>>> } >>>> >>>> private LocalDateTime getLocalDateTimeFromTimestamp(long >>>> timestampMillis) { >>>> return LocalDateTime.ofInstant(Instant.ofEpochSecond(timestampMillis / >>>> 1000), TimeZone.getDefault().toZoneId()); >>>> } >>>> } >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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/20160711/8f3975bd/attachment-0001.html From sthorger at redhat.com Mon Jul 11 06:12:08 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 11 Jul 2016 12:12:08 +0200 Subject: [keycloak-dev] Community curated Keycloak Extensions Repository In-Reply-To: References: Message-ID: I think it would be better to just have a page on the website or in the docs that lists extensions. Having a github repository means we'll need to review and merge PRs for extensions. We just don't have the capacity to do so. On 11 July 2016 at 10:22, Thomas Darimont wrote: > Hello Group, > > I was wondering whether it would make sense have some kind of > community backed keycloak-extensions organisation on github in order > to collect various extensions to Keycloak. > > This organisation could contain repositories with community curated > extensions > that would be independently released from keycloak with installation > descriptions > with JBoss CLI scripts for installing them. > > For instance: > - FederationProviders > - EventListeners > - Authenticators > - RequiredActions > - Themes > - Docker Containers > > Cheers, > Thomas > > _______________________________________________ > 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/20160711/295c79ad/attachment.html From sthorger at redhat.com Mon Jul 11 06:13:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 11 Jul 2016 12:13:03 +0200 Subject: [keycloak-dev] Scope parameter support In-Reply-To: <57834C28.7090309@redhat.com> References: <577524F4.9070803@redhat.com> <5776635C.1000606@redhat.com> <1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com> <5776C857.2070703@redhat.com> <577E08A0.4010409@redhat.com> <577F9794.6060904@redhat.com> <57834C28.7090309@redhat.com> Message-ID: On 11 July 2016 at 09:35, Marek Posolda wrote: > On 11/07/16 08:22, Stian Thorgersen wrote: > > > > On 8 July 2016 at 14:07, Marek Posolda wrote: > >> On 07/07/16 12:07, Stian Thorgersen wrote: >> >> >> >> On 7 July 2016 at 09:45, Marek Posolda < >> mposolda at redhat.com> wrote: >> >>> On 04/07/16 09:47, Stian Thorgersen wrote: >>> >>> ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure >>> how it would look like to an end-user. >>> >>> * Are these managed on a separate screen or on the protocol mappers >>> screen? >>> >>> I am thinking about the protocolMappers screen. Just add another "type" >>> of protocolMapper. This means that we don't need to add another >>> concept/modelType just for scope parameter, but still we can easily >>> filter/view the available mappers of type 'scope aggregator' (on the screen >>> with list of all protocolMappers). >>> >> >> Not quite sure I see why it should be on the protocol mappers screen. As >> it's a separate type of mapper as well the UI to define them would be >> different I'm not sure I see why it can't be a separate screen. >> >> I think it would fit better on the scope tab. It could have two tabs >> "Default scope" and "Scopes" or something like that. >> >> Not sure which place is better. However I am maybe slightly more for >> protocolMappers screen because: >> >> - It just looks a bit more intuitive to me if all the things, which are >> represented at model/DB level by protocolMapper entity are also in admin >> console grouped together on single place. But maybe it's just me ;-) >> > >> >> - For the aggregated mapper, you can select that "children" mappers will >> be either simple mappers or other aggregated mappers. For example for the >> "full-profile" mapper, you can select that it's child is another aggregated >> mapper "profile" together with some additional simple mappers like >> "first_name" or "last_name" . Hence in the list of available mappers, you >> should be able to see both simple and aggregated mappers. >> Isn't it then a bit confusing that you will see both the simple mappers >> like "firstName" (which are configured in "mappers" tab) together with >> aggregated mappers like "profile" (which are configured under >> "scope/default scope" tab) together? >> > > You lost me a bit here. I think I may have miss understood something you > explained before. > > My assumption was that there are two separate things: regular mappers and > scope mappers. Regular mappers are configured as before, while scope > mappers are configured for each scope. So there would be separate screens > in either case. Maybe I'm wrong here, but I could see a page that lists all > scopes, then you can click on the scope to see what mappers are applied as > well as what roles are applied. > > I was thinking about ScopeAggregatedMapper just like about another > implementation of ProtocolMapper interface. No another special model or > special mapper type, which Keycloak needs to deal with. The Keycloak > (TokenManager) will treat like any other mapper, so will just call > "transformAccessToken" to it and ScopeAggregatedMapper impl will delegate > to other children mappers and apply roles. > > The difference is, that UI will need to be a bit special then for other > mappers. There is possibility that we will add the support showing list of > roles and protocolMappers to the directive "kc-provider-config" . However > it looks the better option might be that particular protocolMapper > implementation (or particular provider implementation in general) has a way > to override the angular template with it's own UI if it wants to do it. > > For example, if there is protocolMapper provider with id "foo" then > angular will: > - First look if there is special screen "protocol-mapper-detail_foo.html" . > - If the screen doesn't exist, it will fallback to default > "protocol-mapper-detail.html" screen with the "kc-provider-config" > directive for generic properties. > > For the protocolMapper, the scopeAggregatedMapper will have special screen > "protocol-mapper-detail_scope-aggregate.html" when all other impls just use > the generic screen like now. > > > Maybe it's time to do some mock screens or wire frames? > > +1 > > or start prototyping and see how it goes? :) > Prototyping is just a superior mock ;) > > > Marek > > > >> >> >> Btv. Our current providerModel classes usually have something like: >> >> Map config; >> >> on them. However for the aggregated mapper impl, it may be needed to >> extend this to: >> >> Map> config; >> >> as mapper will need to have the property with the list of children >> mappers and property with the list of children roles. The question is, how >> to represent it in DB? I can see possibilities like: >> a) The value at DB level will be just simple string with children values >> divided by some delimiter (eg. "mapper123###mapper456###mapper789" ) >> b) The value will be list at DB level with separate record for every >> value (eg. 3 values like "mapper123" , "mapper456" , "mapper789" ) >> >> It seems the (b) is a bit harder for migration, but likely the more >> proper way to address this? It looks like something to keep in mind once we >> refactor to the "unified" providerModel table. >> >> >> >>> >>> * How do users define and view scopes, including viewing what >>> claims/mappers/roles are associated with a scope? >>> * How does a user add/remove claims, protocol mappers and roles to >>> a ScopeAggregatorProtocolMapper? >>> >>> I am thinking that for roles, you will select the roles in same way, >>> like it's in current "Scopes" tab of client (or "role mappings" tab of >>> user). Probably very similar UI can be used for selecting "children" >>> mappers of current protocolMapper though? Something like "Available >>> mappers" and "Assigned mappers" and buttons like "Add selected" and "Remove >>> selected". Also similarly like for roles, you can view in "Effective >>> mappers" the list of all effective mappers in case that you have more >>> composed aggregated scopeAggregatorMappers. >>> >>> For example, if you have mapper for scope parameter "full-profile", >>> which will have children mappers, that will point to other scope aggregated >>> mappers : "profile" , "email" and "phone". Hence in "Effective mappers" for >>> "full-profile" you will see all the descendants, not just the direct >>> children. So you will see also all the simple attribute mappers like >>> "firstName", "lastName", "birthday", "phone number", ... >>> >> >> Sounds good >> >> >>> >>> * Do we provide one or more built-in ScopeAggregatorProtocolMapper that >>> are configurable? I assume so and that users don't have to programatically >>> define scopes. >>> >>> Yes. I think that we should provide those built-in, which are specified >>> by OIDC specification. Which is "profile" , "email" , "phone" , "address". >>> And we will need to define mappers for all their simple attributes ( >>> "birthday", "gender" , ...) . Those simple mappers like "birthday" won't be >>> root mappers by default, so they won't be applied unless the scope >>> parameter is used (for their parent scopeAggregatorMapper). >>> >>> For backwards compatibility, we will still use the same 'simple' mappers >>> like now ( username, email, full name, family name, given name) and they >>> will be added to token by default. The scopeAggregator mappers (and their >>> corresponding children) will be applied just if the scope parameter with >>> corresponding value will be used. >>> >> >> SAML doesn't have this concept does it? If so it probably doesn't even >> make sense to show scope mappers for SAML clients. >> >> I don't think that SAML has something like scope parameter. At least I am >> not aware of that :-) >> >> However our SAML clients currently have "Scope" tab visible to map which >> realm roles (or client roles) are allowed to be put into SAML assertion. >> That works same like for OIDC clients and makes sense to keep. I guess you >> meant to hide just the new sub-tab of the "Scope" tab for configure scope >> parameter? >> >> Marek >> >> >> >>> >>> >> >>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper? >>> >>> Yes (see above) >>> >>> Marek >>> >>> >>> On 1 July 2016 at 21:45, Marek Posolda < >>> mposolda at redhat.com> wrote: >>> >>>> Ok, I wasn't also 100% keen about using role. >>>> >>>> Thinking also about what Pedro mentioned before about protocol mappers. >>>> So I wonder that instead of introduce new "scope" concept, we just reuse >>>> protocolMappers SPI and have special impl of protocolMapper, which is able >>>> to deal with scope parameter and aggregate other "children" protocolMappers >>>> and roles? >>>> >>>> Something like this: >>>> - There will be new ProtocolMapper implementation like >>>> ScopeAggregatorProtocolMapper. You will define value of scope parameter >>>> (eg. "photo" ) in the configuration of this protocolMapper. Mapper will be >>>> ignored if scope parameter value with this name was not used. >>>> >>>> - You will be able to define "children" protocolMappers and "children" >>>> roles in ScopeAggregatorProtocolMapper. >>>> >>>> - For each client (and clientTemplate), we will have many defined >>>> protocolMappers, but just some subset of them are "root" mappers, which are >>>> applied by default. The rest of mappers will be used just as "children" of >>>> root mappers. So in client model, we might have: >>>> client.getDefinedProtocolMappers() // all defined >>>> client.getProtocolMappers() // just subset of defined (defacto root >>>> mappers) >>>> >>>> - For example: client will have defined protocolMappers: firstName, >>>> lastName, birthday, profile, email. Just "profile" and "email" will be root >>>> mappers. And "profile" is ScopeAggregatorMapper for scope value "profile" >>>> and it's children mappers are : firstName, lastName, birthday. >>>> >>>> So then: >>>> -- user will send "scope=profile" . Then defacto all of "firstName", >>>> "lastName", "birthday", "email" claims will be included in token. On >>>> consent screen will be just "Profile" and "Email" >>>> -- user won't send "scope=profile" . Then defacto just "email" claim >>>> will be included (So for this example, email is always included even if not >>>> specified by scope parameter). >>>> >>>> - With this concept, we are able to aggregate many various claims into >>>> single value of "scope" and on the consent screen have just the roots. This >>>> would fit well for the default scope values mentioned by OIDC specs. We are >>>> also able to define mappers (claims), which will be always available even >>>> if not specified by scope parameter. >>>> >>>> - For the roles, I am not 100% sure whether to include them into the >>>> concept or not? However it seems to me that rather yes. The particular role >>>> will be applied into token just if all of those 3 conditions are met: >>>> 1) user is member of the role >>>> 2) client has scope for the role (so current "scope" tab in clients >>>> will remain as is) >>>> 3) if role has scopePAramRequired=true, then it must be included in >>>> some mapper (in other words, those roles are not included directly in >>>> clientSession.getRoles , but it's the responsibility of >>>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are >>>> met). >>>> >>>> So again, user won't see all children roles on consent screen. Just the >>>> parent protocolMapper. >>>> >>>> This will work fine with "scope=offline_access" . There will be >>>> protocolMapper for "offline_access" parameter, which will aggregate just >>>> one children role (the current realm role "offline_access"). The offline >>>> token will be issued just if accessToken will have "offline_access" >>>> permission. So if some client, doesn't need offline tokens, it can just >>>> remove "offline_access" protocolMapper. Also if some user shouldn't be >>>> allowed to request offline tokens, admin can remove him from the >>>> "offline_access" role. >>>> >>>> - If some scope parameter is applicable for more clients, it can be >>>> defined on clientTemplate. >>>> >>>> >>>> PS: I will be on holidays and back on next Thursday 7th July. So sorry >>>> if I won't reply immediately to next mails. >>>> >>>> Mare >>>> >>>> >>>> >>>> On 01/07/16 14:57, Pedro Igor Silva wrote: >>>> >>>>> Reading all of this makes me think it would be cleaner to introduce a >>>>>> separate scope concept ;) >>>>>> >>>>>> A user doesn't have a scope - a user has roles and attributes. >>>>>> Re-using roles >>>>>> concept for the scope just makes it feel awkward and retrofitted. >>>>>> >>>>> +10000 >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160711/efbcbeb9/attachment-0001.html From thomas.darimont at googlemail.com Mon Jul 11 06:16:44 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 11 Jul 2016 12:16:44 +0200 Subject: [keycloak-dev] Community curated Keycloak Extensions Repository In-Reply-To: References: Message-ID: Okay, I'm preparing a link list for Keycloak in the vein of: https://github.com/sindresorhus/awesome https://github.com/thomasdarimont/awesome-keycloak/ Cheers, Thomas 2016-07-11 12:12 GMT+02:00 Stian Thorgersen : > I think it would be better to just have a page on the website or in the > docs that lists extensions. Having a github repository means we'll need to > review and merge PRs for extensions. We just don't have the capacity to do > so. > > On 11 July 2016 at 10:22, Thomas Darimont > wrote: > >> Hello Group, >> >> I was wondering whether it would make sense have some kind of >> community backed keycloak-extensions organisation on github in order >> to collect various extensions to Keycloak. >> >> This organisation could contain repositories with community curated >> extensions >> that would be independently released from keycloak with installation >> descriptions >> with JBoss CLI scripts for installing them. >> >> For instance: >> - FederationProviders >> - EventListeners >> - Authenticators >> - RequiredActions >> - Themes >> - Docker Containers >> >> Cheers, >> Thomas >> >> _______________________________________________ >> 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/20160711/21ac0470/attachment.html From bruno at abstractj.org Mon Jul 11 06:21:30 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 11 Jul 2016 07:21:30 -0300 Subject: [keycloak-dev] Community curated Keycloak Extensions Repository In-Reply-To: References: Message-ID: <20160711102130.GA5455@abstractj.org> On 2016-07-11, Stian Thorgersen wrote: > I think it would be better to just have a page on the website or in the > docs that lists extensions. Having a github repository means we'll need to > review and merge PRs for extensions. We just don't have the capacity to do > so. +1 for just link to the relevant repositories > > On 11 July 2016 at 10:22, Thomas Darimont > wrote: > > > Hello Group, > > > > I was wondering whether it would make sense have some kind of > > community backed keycloak-extensions organisation on github in order > > to collect various extensions to Keycloak. > > > > This organisation could contain repositories with community curated > > extensions > > that would be independently released from keycloak with installation > > descriptions > > with JBoss CLI scripts for installing them. > > > > For instance: > > - FederationProviders > > - EventListeners > > - Authenticators > > - RequiredActions > > - Themes > > - Docker Containers > > > > Cheers, > > Thomas > > > > _______________________________________________ > > 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 -- abstractj PGP: 0x84DC9914 From yunusoncel at gmail.com Mon Jul 11 07:36:51 2016 From: yunusoncel at gmail.com (=?UTF-8?B?WXVudXMgw5ZOQ0VM?=) Date: Mon, 11 Jul 2016 14:36:51 +0300 Subject: [keycloak-dev] Editable effective Roles Message-ID: I have a simple and short Question is it possible? I want editable assigned roles (effective roles). Example A Person have a composite Role(10 Role ) and B Person have too a same composite role (9 roles) . I don't want create new composite role to a role. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160711/bb8c379d/attachment.html From mposolda at redhat.com Mon Jul 11 09:06:51 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 11 Jul 2016 15:06:51 +0200 Subject: [keycloak-dev] Editable effective Roles In-Reply-To: References: Message-ID: <578399EB.2060206@redhat.com> Nope, that's not possible by design. You can think about composite role as group of other roles. For example if you have composite role "admin" , which consists of 3 child roles "administer-finance" , "administer-sales" , "administer-stuff" , then it means that if you assign the role "admin" to some user, he really has permissions to administer everything (so 3 other roles). If you need something more fine-grained, then you need something like separate composite roles for every group of roles (so in your case, one composite role for your 10 roles to be assigned to PersonA and second composite role for your 9 roles to be assigned to personB). Or if it should be even more fine-grained, then maybe composite roles is not a way to go for you. Marek On 11/07/16 13:36, Yunus ?NCEL wrote: > I have a simple and short Question > > is it possible? I want editable assigned roles (effective roles). > Example A Person have a composite Role(10 Role ) and B Person have too > a same composite role (9 roles) . I don't want create new composite > role to a role. > > Thank you > > > _______________________________________________ > 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/20160711/0ebe360e/attachment.html From sthorger at redhat.com Tue Jul 12 05:50:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 12 Jul 2016 11:50:03 +0200 Subject: [keycloak-dev] Keycloak SSL Reverse Proxy settings In-Reply-To: References: Message-ID: I'm pretty sure there's no changes. Has anything changed in your proxy setup? Does it still work with 1.9.2, but the exact same config doesn't work with 2.0.0? On 8 July 2016 at 10:59, gambol wrote: > Hiya > > > We've been running v1.9.2 behind a nginx proxy for some time now. Has the > setup for running Keycloak v2.0.0-Final behind a proxy changed? ... We've > kept the amended lines, but Keycloak is returns content in non-https > appearing to ignore the X-Forwarded-Proto > > ? > proxy-address-forwarding="true" redirect-socket="proxy-https"/> > ... > > > > > > > > <--- > > ... > ------------------------------ > > But looking at the urls handed back, they are all http:// > > > Doing a tcpdump dump between proxy and keycloak, I can see the X-Forwarded > headers added by the proxy > > GET /auth/admin/master/console/ HTTP/1.0 > X-Real-IP: 127.0.0.1 > X-Forwarded-For: 127.0.0.1 > X-Forwarded-Proto: https > Host: 127.0.0.1 > Connection: close > Cache-Control: max-age=0 > Upgrade-Insecure-Requests: 1 > User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, > like Gecko) Chrome/51.0.2704.106 Safari/537.36 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp, > */*;q=0.8 > Accept-Encoding: gzip, deflate, sdch, br > Accept-Language: en-US,en;q=0.8 > > > > _______________________________________________ > 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/20160712/5bdb78e2/attachment.html From christian at datek.no Tue Jul 12 07:24:25 2016 From: christian at datek.no (Christian Schwarz) Date: Tue, 12 Jul 2016 11:24:25 +0000 Subject: [keycloak-dev] Keycloak spring security adapter - possible to set http / pool timeouts for outgoing connections? Message-ID: <719ED0C9-BA90-451D-9DAA-D5AD6316D6A2@datek.no> Hello! I?m using the Keycloak spring security adapter. My clients are using HTTP Basic Authentication, which will then result in a HTTP request to validate those credentials (from the adapter to the keycloak server). The problem is that the adapter does not have a timeout on these remote invocations towards the keycloak server. It only allows configuring the connection pool size, which is default = 100. I have on multiple occations had my main application exhausted of HTTP serving threads because all of them are waiting for keycloak adapter credentials validation (remote invocations). (why the server does not respond is another matter :) I.e. all my HTTP serving threads are stuck in this state: java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f15cd418> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at org.apache.http.impl.conn.tsccm.WaitingThread.await(WaitingThread.java:162) at org.apache.http.impl.conn.tsccm.ConnPoolByRoute.getEntryBlocking(ConnPoolByRoute.java:400) at org.apache.http.impl.conn.tsccm.ConnPoolByRoute$1.getPoolEntry(ConnPoolByRoute.java:300) at org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager$1.getConnection(ThreadSafeClientConnManager.java:242) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:424) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.keycloak.adapters.BasicAuthRequestAuthenticator.getToken(BasicAuthRequestAuthenticator.java:103) at org.keycloak.adapters.BasicAuthRequestAuthenticator.authenticate(BasicAuthRequestAuthenticator.java:75) at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:83) at org.keycloak.adapters.springsecurity.filter.KeycloakAuthenticationProcessingFilter.attemptAuthentication(KeycloakAuthenticationProcessingFilter.java:137) at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:217) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) at no.datek.iot.home.security.InternalClientAuthenticationFilter.doFilterInternal(InternalClientAuthenticationFilter.java:38) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:120) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) at org.keycloak.adapters.springsecurity.filter.KeycloakPreAuthActionsFilter.doFilter(KeycloakPreAuthActionsFilter.java:84) Is it possible to set a timeout (both for TCP connect and for socket read) on these keycloak adapter outgoing connections? (to prevent the connection pool from blocking) It would also be really nice to be able to set the timeout on getting connections from that pool ("connection manager timeout"), to prevent connections from queueing up even if the other timeouts are set (important if there are lots of connections coming in). I know apache http client has settings for all these three values. Keep up the good work! Best regards, Christian Schwarz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160712/71298d76/attachment-0001.html From mitya at cargosoft.ru Tue Jul 12 07:42:58 2016 From: mitya at cargosoft.ru (Mitya) Date: Tue, 12 Jul 2016 14:42:58 +0300 Subject: [keycloak-dev] Preferred storage mechanism for custom settings Message-ID: <1468323778.4229.4.camel@cargosoft.ru> Hi, I'm developing a KeyCloak extension, and I want some custom (per-realm) parameters to be tuned via the GUI form. Speaking of the storage mechanism for my settings, are realm attributes suitable for that? or should I create a dedicated custom entity instead? Thx, Mitya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160712/42de0dcd/attachment.html From sthorger at redhat.com Tue Jul 12 07:53:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 12 Jul 2016 13:53:11 +0200 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: <1468323778.4229.4.camel@cargosoft.ru> References: <1468323778.4229.4.camel@cargosoft.ru> Message-ID: Realm attributes should be perfect for that On 12 July 2016 at 13:42, Mitya wrote: > Hi, > > I'm developing a KeyCloak extension, and I want some custom (per-realm) > parameters to be tuned via the GUI form. Speaking of the storage mechanism > for my settings, are realm attributes suitable for that? or should I create > a dedicated custom entity instead? > > Thx, > Mitya > > _______________________________________________ > 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/20160712/1d290898/attachment.html From josh.cain at redhat.com Tue Jul 12 13:22:31 2016 From: josh.cain at redhat.com (Josh Cain) Date: Tue, 12 Jul 2016 12:22:31 -0500 Subject: [keycloak-dev] Authorization Code Flow as Default for Javascript? Message-ID: Hi All, We're looking to start rolling the Keycloak OIDC flow out to some client-side Javascript applications, and I came across a question in coming up to speed on OIDC. You state in your docs that the Javascript adapter is intended for client-side use: Keycloak comes with a client-side JavaScript library that can be used to > secure HTML5/JavaScript applications. > The docs also state that the default flow for this adapter is the Authorization Code flow: By default, the JavaScript adapter uses the Authorization Code > flow. > However, the OIDC spec says (section 3.1): ...The Authorization Code flow is suitable for Clients that can securely > maintain a Client Secret between themselves and the Authorization Server. > And again echoes the sentiment using the non-requisite MAY language in section 15.4: In general, it is up to Relying Parties which features they use when > interacting with OpenID Providers. However, some choices are dictated by > the nature of their OAuth Client, such as whether it is a Confidential > Client, capable of keeping secrets, in which case the Authorization Code > Flow may be appropriate, or whether it is a Public Client, for instance, a > User Agent Based Application or a statically registered Native Application, > in which case the Implicit Flow may be appropriate. > I'm aware that public clients who do not present a client secret are allowed under the OAuth spec , and that these are often the type of javascript client that Keycloak sets up with the authorization code flow. What's more, I understand that the client secret is most commonly the reason cited for the client/server distinction with respect to flows. However, I was curious as to why the authorization code flow remains the default setting for Javascript applications. Isn't the refresh token also considered a form of a 'secret' since it's a long-lived mechanism whereby additional access/identity tokens can be retrieved? Why would the default setting *not* be implicit here? Could you help me understand why the authorization code flow was chosen as the default? Thanks in advance! Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160712/712b0e44/attachment.html From ssilvert at redhat.com Tue Jul 12 15:00:13 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 12 Jul 2016 15:00:13 -0400 Subject: [keycloak-dev] Admin Realm in keycloak-server.json Message-ID: <57853E3D.1020501@redhat.com> keycloak-server.json has this: "admin": { "realm": "master" }, Is it possible to have more than one admin realm or to have any other values under admin? Could it just be this?: "admin-realm" : "master" From sthorger at redhat.com Wed Jul 13 01:27:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 13 Jul 2016 07:27:11 +0200 Subject: [keycloak-dev] Admin Realm in keycloak-server.json In-Reply-To: <57853E3D.1020501@redhat.com> References: <57853E3D.1020501@redhat.com> Message-ID: It can be a single attribute sure, I'd probably just call it "master-realm-name". On 12 July 2016 at 21:00, Stan Silvert wrote: > keycloak-server.json has this: > > "admin": { > "realm": "master" > }, > > Is it possible to have more than one admin realm or to have any other > values under admin? > > Could it just be this?: > > "admin-realm" : "master" > _______________________________________________ > 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/20160713/9e1bdafb/attachment.html From sthorger at redhat.com Wed Jul 13 02:37:30 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 13 Jul 2016 08:37:30 +0200 Subject: [keycloak-dev] Authorization Code Flow as Default for Javascript? In-Reply-To: References: Message-ID: With Implicit flow it's usual to have a long expiration on access tokens as there is no refresh token. Once the access token is expired you're left with having to do the whole OAuth redirect dance again to obtain a new token. What's even worse is that if you have long lived access tokens there's potentially a longer time between the verification of the access token directly with Keycloak, which means that an access token could potentially be used long after the session has been removed. With that in mind having short lived access tokens with a refresh token is better in our opinion even for public clients. On 12 July 2016 at 19:22, Josh Cain wrote: > Hi All, > > We're looking to start rolling the Keycloak OIDC flow out to some > client-side Javascript applications, and I came across a question in coming > up to speed on OIDC. You state in your docs > > that the Javascript adapter is intended for client-side use: > > Keycloak comes with a client-side JavaScript library that can be used to >> secure HTML5/JavaScript applications. >> > > The docs also state that the default flow for this adapter is the > Authorization Code flow: > > By default, the JavaScript adapter uses the Authorization Code >> flow. >> > > However, the OIDC spec > says (section 3.1): > > ...The Authorization Code flow is suitable for Clients that can securely >> maintain a Client Secret between themselves and the Authorization Server. >> > > And again echoes the sentiment using the non-requisite MAY language in > section 15.4: > > In general, it is up to Relying Parties which features they use when >> interacting with OpenID Providers. However, some choices are dictated by >> the nature of their OAuth Client, such as whether it is a Confidential >> Client, capable of keeping secrets, in which case the Authorization Code >> Flow may be appropriate, or whether it is a Public Client, for instance, a >> User Agent Based Application or a statically registered Native Application, >> in which case the Implicit Flow may be appropriate. >> > > I'm aware that public clients who do not present a client secret are > allowed under the OAuth spec , and > that these are often the type of javascript client that Keycloak sets up > with the authorization code flow. What's more, I understand that the > client secret is most commonly the reason cited for the client/server > distinction with respect to flows. > > However, I was curious as to why the authorization code flow remains the > default setting for Javascript applications. Isn't the refresh token also > considered a form of a 'secret' since it's a long-lived mechanism whereby > additional access/identity tokens can be retrieved? Why would the default > setting *not* be implicit here? Could you help me understand why the > authorization code flow was chosen as the default? > > Thanks in advance! > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > _______________________________________________ > 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/20160713/9e14cd5e/attachment-0001.html From wadahiro at gmail.com Thu Jul 14 07:29:56 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Thu, 14 Jul 2016 11:29:56 +0000 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: Thank you for merging the pull request. Could I send a pull request converting to UTF-8 encoding against the theme properties? 2016?7?7?(?) 21:39 Hiroyuki Wada : > Yes. I will send a pull request later! > > 2016?7?7?(?) 21:20 Stian Thorgersen : > >> Are you doing a PR as well? >> >> On 7 July 2016 at 12:33, Hiroyuki Wada wrote: >> >>> Ok. I created a JIRA issue. >>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>> >>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>> >>>> Let's go for it. Please create a JIRA and send PR. Please just use "# >>>> encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter is just >>>> weird if you ask me. >>>> >>>> Thomas: It's optional, defaults to iso-8859-1 and the header will >>>> clearly state that a file uses a different encoding, so I disagree that >>>> there will be any confusion. >>>> >>>> On 6 July 2016 at 12:30, Hiroyuki Wada wrote: >>>> >>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>> wrote: >>>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>>> .properties is >>>>> > still expected to be ISO-8859-1: >>>>> > >>>>> >> Constructing a PropertyResourceBundle instance from an InputStream >>>>> >> requires that the input stream be encoded in ISO-8859-1. In that >>>>> case, >>>>> >> characters that cannot be represented in ISO-8859-1 encoding must be >>>>> >> represented by Unicode Escapes as defined in section 3.3 of The >>>>> Java? >>>>> >> Language Specification whereas the other constructor which takes a >>>>> Reader >>>>> >> does not have that limitation. >>>>> >>>>> It's a case of using constructor which takes an InputStream. >>>>> It says we can use any encoding when we use the other constructor >>>>> which takes a Reader. >>>>> >>>>> I understand your concern. So what do you think supporting utf-8 with >>>>> a header like Stian suggested? >>>>> I think it can avoid confusion because the encoding is noted in the >>>>> file itself... >>>>> >>>>> Regards, >>>>> >>>>> > >>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>> > >>>>> > I understand that Spring allows one to read .properties using any >>>>> encoding, >>>>> > but you need to specify the encoding in Spring configuration >>>>> external to the >>>>> > .properties file. >>>>> > >>>>> > In my opinion it would cause unnecessary confusion amongst >>>>> developers to use >>>>> > any other encoding than the one defined by the official >>>>> documentation for >>>>> > Properties. >>>>> > >>>>> > Best regards, >>>>> > Thomas >>>>> > >>>>> > >>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada >>>>> wrote: >>>>> >> >>>>> >> I think it was true before Java 1.6 because Java standard library >>>>> >> (java.util.ResourceBundle or java.util.Properties) only supported >>>>> >> ISO-8859-1 encoding file. >>>>> >> But they support any encoding after Java 1.6. There are some >>>>> >> frameworks which can read .properties with any encoding. For >>>>> example, >>>>> >> Spring Framework can read .properties with any encoding. I think >>>>> it's >>>>> >> very useful to read UTF-8 directly for multibyte language country. >>>>> >> >>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>> >> wrote: >>>>> >> > Please correct me if I am wrong, but I have been under the >>>>> impression >>>>> >> > that >>>>> >> > Java .properties files should always use encoding ISO-8859-1. >>>>> Characters >>>>> >> > not >>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make >>>>> things >>>>> >> > confusing to developers if another encoding is used here instead? >>>>> >> > >>>>> >> > >>>>> >> > >>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>> >> > >>>>> >> > >>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>> >> > >>>>> >> > If alternate encodings are desired how about supporting the XML >>>>> format >>>>> >> > of >>>>> >> > Properties? >>>>> >> > >>>>> >> > Best regards, >>>>> >> > Thomas >>>>> >> > >>>>> >> > >>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>> sthorger at redhat.com> >>>>> >> > wrote: >>>>> >> >> >>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >>>>> co-exist. >>>>> >> >> >>>>> >> >> We can allow specifying the encoding in a comment on the first >>>>> line >>>>> >> >> like >>>>> >> >> this: >>>>> >> >> >>>>> >> >> # encoding=utf-8 >>>>> >> >> key=value >>>>> >> >> >>>>> >> >> # encoding=iso-8859-1 >>>>> >> >> key=value >>>>> >> >> >>>>> >> >> If the first line in the file doesn't contain the comment with >>>>> the >>>>> >> >> encoding then we should default to iso-8859-1 for backwards >>>>> >> >> compatibility >>>>> >> >> >>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada >>>>> wrote: >>>>> >> >>> >>>>> >> >>> Thanks for your comment. >>>>> >> >>> >>>>> >> >>> > If we want to change to utf-8 we'd still need to support >>>>> iso.. for >>>>> >> >>> > backwards compatibility. >>>>> >> >>> >>>>> >> >>> If we change to UTF-8, we can still read unicode codepoint like >>>>> >> >>> '\u00e8'. >>>>> >> >>> There is an incompatibility when non-ascii characters are used >>>>> in >>>>> >> >>> message properties. >>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer >>>>> codepage >>>>> >> >>> layout: >>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>> >> >>> >>>>> >> >>> I think the non-ascii characters might be used in French >>>>> messages like >>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>> compatibility. >>>>> >> >>> To support this, I think we can add a property like >>>>> "messageEncoding" >>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>> >> >>> >>>>> >> >>> "theme": { >>>>> >> >>> "staticMaxAge": 2592000, >>>>> >> >>> "cacheTemplates": true, >>>>> >> >>> "cacheThemes": true, >>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>> >> >>> "folder": { >>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>> >> >>> } >>>>> >> >>> }, >>>>> >> >>> >>>>> >> >>> Regards, >>>>> >> >>> >>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>> >> >>> >>>>> >> >>> wrote: >>>>> >> >>> > We have in the past discussed this and decided to stick with >>>>> >> >>> > ISO-8859-1. >>>>> >> >>> > That was probably not the best idea though. If we want to >>>>> change to >>>>> >> >>> > utf-8 >>>>> >> >>> > we'd still need to support iso.. for backwards compatibility. >>>>> >> >>> > >>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira >>>>> wrote: >>>>> >> >>> >> >>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>> >> >>> >> >>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>> >> >>> >> > Hello all, >>>>> >> >>> >> > >>>>> >> >>> >> > I am trying to translate all base theme messages to my >>>>> country >>>>> >> >>> >> > language, Japanese. And I'd like to contribute them. >>>>> Before that >>>>> >> >>> >> > work, >>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>> >> >>> >> > >>>>> >> >>> >> > Currently, the message files (*.properties) are loaded with >>>>> >> >>> >> > ISO-8859-1 >>>>> >> >>> >> > encoding. Therefore, it is necessary to convert the files >>>>> by >>>>> >> >>> >> > 'native2ascii' command beforehand. However we can directly >>>>> read >>>>> >> >>> >> > the >>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or later >>>>> because >>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >>>>> introduced >>>>> >> >>> >> > as >>>>> >> >>> >> > below. >>>>> >> >>> >> > >>>>> >> >>> >> > >>>>> >> >>> >> > >>>>> >> >>> >> > >>>>> >> >>> >> > >>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>> >> >>> >> > >>>>> >> >>> >> > So, my proposal is supporting the message files with UTF-8 >>>>> >> >>> >> > encoding. >>>>> >> >>> >> > I >>>>> >> >>> >> > believe that it's very developers/customers friendly. In >>>>> >> >>> >> > addition, >>>>> >> >>> >> > we >>>>> >> >>> >> > can easily review the translated messages on the github >>>>> pull >>>>> >> >>> >> > request >>>>> >> >>> >> > view and so on. What do you think? >>>>> >> >>> >> > >>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >>>>> request. >>>>> >> >>> >> > >>>>> >> >>> >> > Regards, >>>>> >> >>> >> > >>>>> >> >>> >> > -- >>>>> >> >>> >> > Hiroyuki Wada, >>>>> >> >>> >> > Developer, >>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>> >> >>> >> > _______________________________________________ >>>>> >> >>> >> > keycloak-dev mailing list >>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >> >>> >> >>>>> >> >>> >> -- >>>>> >> >>> >> >>>>> >> >>> >> abstractj >>>>> >> >>> >> PGP: 0x84DC9914 >>>>> >> >>> >> _______________________________________________ >>>>> >> >>> >> 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 >>>>> >> > >>>>> >> > >>>>> >> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> _______________________________________________ >>>>> 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/20160714/9d5b24d7/attachment.html From sthorger at redhat.com Fri Jul 15 01:03:18 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Jul 2016 07:03:18 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: No, we don't want the theme properties (and other properties files) to be utf-8. They should stick with the default encoding used by Java properties files. Messages are a special case, which is why we accepted it for them. On 14 July 2016 at 13:29, Hiroyuki Wada wrote: > Thank you for merging the pull request. Could I send a pull request > converting to UTF-8 encoding against the theme properties? > > 2016?7?7?(?) 21:39 Hiroyuki Wada : > >> Yes. I will send a pull request later! >> >> 2016?7?7?(?) 21:20 Stian Thorgersen : >> >>> Are you doing a PR as well? >>> >>> On 7 July 2016 at 12:33, Hiroyuki Wada wrote: >>> >>>> Ok. I created a JIRA issue. >>>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>>> >>>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>>> >>>>> Let's go for it. Please create a JIRA and send PR. Please just use "# >>>>> encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter is >>>>> just weird if you ask me. >>>>> >>>>> Thomas: It's optional, defaults to iso-8859-1 and the header will >>>>> clearly state that a file uses a different encoding, so I disagree that >>>>> there will be any confusion. >>>>> >>>>> On 6 July 2016 at 12:30, Hiroyuki Wada wrote: >>>>> >>>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>>> wrote: >>>>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>>>> .properties is >>>>>> > still expected to be ISO-8859-1: >>>>>> > >>>>>> >> Constructing a PropertyResourceBundle instance from an InputStream >>>>>> >> requires that the input stream be encoded in ISO-8859-1. In that >>>>>> case, >>>>>> >> characters that cannot be represented in ISO-8859-1 encoding must >>>>>> be >>>>>> >> represented by Unicode Escapes as defined in section 3.3 of The >>>>>> Java? >>>>>> >> Language Specification whereas the other constructor which takes a >>>>>> Reader >>>>>> >> does not have that limitation. >>>>>> >>>>>> It's a case of using constructor which takes an InputStream. >>>>>> It says we can use any encoding when we use the other constructor >>>>>> which takes a Reader. >>>>>> >>>>>> I understand your concern. So what do you think supporting utf-8 with >>>>>> a header like Stian suggested? >>>>>> I think it can avoid confusion because the encoding is noted in the >>>>>> file itself... >>>>>> >>>>>> Regards, >>>>>> >>>>>> > >>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>>> > >>>>>> > I understand that Spring allows one to read .properties using any >>>>>> encoding, >>>>>> > but you need to specify the encoding in Spring configuration >>>>>> external to the >>>>>> > .properties file. >>>>>> > >>>>>> > In my opinion it would cause unnecessary confusion amongst >>>>>> developers to use >>>>>> > any other encoding than the one defined by the official >>>>>> documentation for >>>>>> > Properties. >>>>>> > >>>>>> > Best regards, >>>>>> > Thomas >>>>>> > >>>>>> > >>>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada >>>>>> wrote: >>>>>> >> >>>>>> >> I think it was true before Java 1.6 because Java standard library >>>>>> >> (java.util.ResourceBundle or java.util.Properties) only supported >>>>>> >> ISO-8859-1 encoding file. >>>>>> >> But they support any encoding after Java 1.6. There are some >>>>>> >> frameworks which can read .properties with any encoding. For >>>>>> example, >>>>>> >> Spring Framework can read .properties with any encoding. I think >>>>>> it's >>>>>> >> very useful to read UTF-8 directly for multibyte language country. >>>>>> >> >>>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>>> >> wrote: >>>>>> >> > Please correct me if I am wrong, but I have been under the >>>>>> impression >>>>>> >> > that >>>>>> >> > Java .properties files should always use encoding ISO-8859-1. >>>>>> Characters >>>>>> >> > not >>>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make >>>>>> things >>>>>> >> > confusing to developers if another encoding is used here instead? >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>>> >> > >>>>>> >> > >>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>>> >> > >>>>>> >> > If alternate encodings are desired how about supporting the XML >>>>>> format >>>>>> >> > of >>>>>> >> > Properties? >>>>>> >> > >>>>>> >> > Best regards, >>>>>> >> > Thomas >>>>>> >> > >>>>>> >> > >>>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>>> sthorger at redhat.com> >>>>>> >> > wrote: >>>>>> >> >> >>>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >>>>>> co-exist. >>>>>> >> >> >>>>>> >> >> We can allow specifying the encoding in a comment on the first >>>>>> line >>>>>> >> >> like >>>>>> >> >> this: >>>>>> >> >> >>>>>> >> >> # encoding=utf-8 >>>>>> >> >> key=value >>>>>> >> >> >>>>>> >> >> # encoding=iso-8859-1 >>>>>> >> >> key=value >>>>>> >> >> >>>>>> >> >> If the first line in the file doesn't contain the comment with >>>>>> the >>>>>> >> >> encoding then we should default to iso-8859-1 for backwards >>>>>> >> >> compatibility >>>>>> >> >> >>>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada >>>>>> wrote: >>>>>> >> >>> >>>>>> >> >>> Thanks for your comment. >>>>>> >> >>> >>>>>> >> >>> > If we want to change to utf-8 we'd still need to support >>>>>> iso.. for >>>>>> >> >>> > backwards compatibility. >>>>>> >> >>> >>>>>> >> >>> If we change to UTF-8, we can still read unicode codepoint like >>>>>> >> >>> '\u00e8'. >>>>>> >> >>> There is an incompatibility when non-ascii characters are used >>>>>> in >>>>>> >> >>> message properties. >>>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer >>>>>> codepage >>>>>> >> >>> layout: >>>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>>> >> >>> >>>>>> >> >>> I think the non-ascii characters might be used in French >>>>>> messages like >>>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>>> compatibility. >>>>>> >> >>> To support this, I think we can add a property like >>>>>> "messageEncoding" >>>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>>> >> >>> >>>>>> >> >>> "theme": { >>>>>> >> >>> "staticMaxAge": 2592000, >>>>>> >> >>> "cacheTemplates": true, >>>>>> >> >>> "cacheThemes": true, >>>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>>> >> >>> "folder": { >>>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>>> >> >>> } >>>>>> >> >>> }, >>>>>> >> >>> >>>>>> >> >>> Regards, >>>>>> >> >>> >>>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>>> >> >>> >>>>>> >> >>> wrote: >>>>>> >> >>> > We have in the past discussed this and decided to stick with >>>>>> >> >>> > ISO-8859-1. >>>>>> >> >>> > That was probably not the best idea though. If we want to >>>>>> change to >>>>>> >> >>> > utf-8 >>>>>> >> >>> > we'd still need to support iso.. for backwards compatibility. >>>>>> >> >>> > >>>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira >>>>>> wrote: >>>>>> >> >>> >> >>>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>> >> >>> >> >>>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>> >> >>> >> > Hello all, >>>>>> >> >>> >> > >>>>>> >> >>> >> > I am trying to translate all base theme messages to my >>>>>> country >>>>>> >> >>> >> > language, Japanese. And I'd like to contribute them. >>>>>> Before that >>>>>> >> >>> >> > work, >>>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>>> >> >>> >> > >>>>>> >> >>> >> > Currently, the message files (*.properties) are loaded >>>>>> with >>>>>> >> >>> >> > ISO-8859-1 >>>>>> >> >>> >> > encoding. Therefore, it is necessary to convert the files >>>>>> by >>>>>> >> >>> >> > 'native2ascii' command beforehand. However we can >>>>>> directly read >>>>>> >> >>> >> > the >>>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or later >>>>>> because >>>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >>>>>> introduced >>>>>> >> >>> >> > as >>>>>> >> >>> >> > below. >>>>>> >> >>> >> > >>>>>> >> >>> >> > >>>>>> >> >>> >> > >>>>>> >> >>> >> > >>>>>> >> >>> >> > >>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>> >> >>> >> > >>>>>> >> >>> >> > So, my proposal is supporting the message files with UTF-8 >>>>>> >> >>> >> > encoding. >>>>>> >> >>> >> > I >>>>>> >> >>> >> > believe that it's very developers/customers friendly. In >>>>>> >> >>> >> > addition, >>>>>> >> >>> >> > we >>>>>> >> >>> >> > can easily review the translated messages on the github >>>>>> pull >>>>>> >> >>> >> > request >>>>>> >> >>> >> > view and so on. What do you think? >>>>>> >> >>> >> > >>>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >>>>>> request. >>>>>> >> >>> >> > >>>>>> >> >>> >> > Regards, >>>>>> >> >>> >> > >>>>>> >> >>> >> > -- >>>>>> >> >>> >> > Hiroyuki Wada, >>>>>> >> >>> >> > Developer, >>>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>>> >> >>> >> > _______________________________________________ >>>>>> >> >>> >> > keycloak-dev mailing list >>>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>>> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >> >>> >> >>>>>> >> >>> >> -- >>>>>> >> >>> >> >>>>>> >> >>> >> abstractj >>>>>> >> >>> >> PGP: 0x84DC9914 >>>>>> >> >>> >> _______________________________________________ >>>>>> >> >>> >> 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 >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> >>>>>> _______________________________________________ >>>>>> 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/20160715/fa4323b8/attachment-0001.html From wadahiro at gmail.com Fri Jul 15 01:59:48 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Fri, 15 Jul 2016 05:59:48 +0000 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: I mean I'd like to change the message files encoding only. For example, admin-messages for Russian language is currently written in ISO-8859-1 encoding. https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/messages/admin-messages_ru.properties Can I convert the language messages except for English? 2016?7?15?(?) 14:03 Stian Thorgersen : > No, we don't want the theme properties (and other properties files) to be > utf-8. They should stick with the default encoding used by Java properties > files. > > Messages are a special case, which is why we accepted it for them. > > On 14 July 2016 at 13:29, Hiroyuki Wada wrote: > >> Thank you for merging the pull request. Could I send a pull request >> converting to UTF-8 encoding against the theme properties? >> >> 2016?7?7?(?) 21:39 Hiroyuki Wada : >> >>> Yes. I will send a pull request later! >>> >>> 2016?7?7?(?) 21:20 Stian Thorgersen : >>> >>>> Are you doing a PR as well? >>>> >>>> On 7 July 2016 at 12:33, Hiroyuki Wada wrote: >>>> >>>>> Ok. I created a JIRA issue. >>>>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>>>> >>>>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>>>> >>>>>> Let's go for it. Please create a JIRA and send PR. Please just use "# >>>>>> encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter is >>>>>> just weird if you ask me. >>>>>> >>>>>> Thomas: It's optional, defaults to iso-8859-1 and the header will >>>>>> clearly state that a file uses a different encoding, so I disagree that >>>>>> there will be any confusion. >>>>>> >>>>>> On 6 July 2016 at 12:30, Hiroyuki Wada wrote: >>>>>> >>>>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>>>> wrote: >>>>>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>>>>> .properties is >>>>>>> > still expected to be ISO-8859-1: >>>>>>> > >>>>>>> >> Constructing a PropertyResourceBundle instance from an InputStream >>>>>>> >> requires that the input stream be encoded in ISO-8859-1. In that >>>>>>> case, >>>>>>> >> characters that cannot be represented in ISO-8859-1 encoding must >>>>>>> be >>>>>>> >> represented by Unicode Escapes as defined in section 3.3 of The >>>>>>> Java? >>>>>>> >> Language Specification whereas the other constructor which takes >>>>>>> a Reader >>>>>>> >> does not have that limitation. >>>>>>> >>>>>>> It's a case of using constructor which takes an InputStream. >>>>>>> It says we can use any encoding when we use the other constructor >>>>>>> which takes a Reader. >>>>>>> >>>>>>> I understand your concern. So what do you think supporting utf-8 with >>>>>>> a header like Stian suggested? >>>>>>> I think it can avoid confusion because the encoding is noted in the >>>>>>> file itself... >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> > >>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>>>> > >>>>>>> > I understand that Spring allows one to read .properties using any >>>>>>> encoding, >>>>>>> > but you need to specify the encoding in Spring configuration >>>>>>> external to the >>>>>>> > .properties file. >>>>>>> > >>>>>>> > In my opinion it would cause unnecessary confusion amongst >>>>>>> developers to use >>>>>>> > any other encoding than the one defined by the official >>>>>>> documentation for >>>>>>> > Properties. >>>>>>> > >>>>>>> > Best regards, >>>>>>> > Thomas >>>>>>> > >>>>>>> > >>>>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada >>>>>>> wrote: >>>>>>> >> >>>>>>> >> I think it was true before Java 1.6 because Java standard library >>>>>>> >> (java.util.ResourceBundle or java.util.Properties) only supported >>>>>>> >> ISO-8859-1 encoding file. >>>>>>> >> But they support any encoding after Java 1.6. There are some >>>>>>> >> frameworks which can read .properties with any encoding. For >>>>>>> example, >>>>>>> >> Spring Framework can read .properties with any encoding. I think >>>>>>> it's >>>>>>> >> very useful to read UTF-8 directly for multibyte language country. >>>>>>> >> >>>>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>>>> >> wrote: >>>>>>> >> > Please correct me if I am wrong, but I have been under the >>>>>>> impression >>>>>>> >> > that >>>>>>> >> > Java .properties files should always use encoding ISO-8859-1. >>>>>>> Characters >>>>>>> >> > not >>>>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make >>>>>>> things >>>>>>> >> > confusing to developers if another encoding is used here >>>>>>> instead? >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>>>> >> > >>>>>>> >> > >>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>>>> >> > >>>>>>> >> > If alternate encodings are desired how about supporting the XML >>>>>>> format >>>>>>> >> > of >>>>>>> >> > Properties? >>>>>>> >> > >>>>>>> >> > Best regards, >>>>>>> >> > Thomas >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>>>> sthorger at redhat.com> >>>>>>> >> > wrote: >>>>>>> >> >> >>>>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >>>>>>> co-exist. >>>>>>> >> >> >>>>>>> >> >> We can allow specifying the encoding in a comment on the first >>>>>>> line >>>>>>> >> >> like >>>>>>> >> >> this: >>>>>>> >> >> >>>>>>> >> >> # encoding=utf-8 >>>>>>> >> >> key=value >>>>>>> >> >> >>>>>>> >> >> # encoding=iso-8859-1 >>>>>>> >> >> key=value >>>>>>> >> >> >>>>>>> >> >> If the first line in the file doesn't contain the comment with >>>>>>> the >>>>>>> >> >> encoding then we should default to iso-8859-1 for backwards >>>>>>> >> >> compatibility >>>>>>> >> >> >>>>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada >>>>>>> wrote: >>>>>>> >> >>> >>>>>>> >> >>> Thanks for your comment. >>>>>>> >> >>> >>>>>>> >> >>> > If we want to change to utf-8 we'd still need to support >>>>>>> iso.. for >>>>>>> >> >>> > backwards compatibility. >>>>>>> >> >>> >>>>>>> >> >>> If we change to UTF-8, we can still read unicode codepoint >>>>>>> like >>>>>>> >> >>> '\u00e8'. >>>>>>> >> >>> There is an incompatibility when non-ascii characters are >>>>>>> used in >>>>>>> >> >>> message properties. >>>>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer >>>>>>> codepage >>>>>>> >> >>> layout: >>>>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>>>> >> >>> >>>>>>> >> >>> I think the non-ascii characters might be used in French >>>>>>> messages like >>>>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>>>> compatibility. >>>>>>> >> >>> To support this, I think we can add a property like >>>>>>> "messageEncoding" >>>>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>>>> >> >>> >>>>>>> >> >>> "theme": { >>>>>>> >> >>> "staticMaxAge": 2592000, >>>>>>> >> >>> "cacheTemplates": true, >>>>>>> >> >>> "cacheThemes": true, >>>>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>>>> >> >>> "folder": { >>>>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>>>> >> >>> } >>>>>>> >> >>> }, >>>>>>> >> >>> >>>>>>> >> >>> Regards, >>>>>>> >> >>> >>>>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>>>> >> >>> >>>>>>> >> >>> wrote: >>>>>>> >> >>> > We have in the past discussed this and decided to stick with >>>>>>> >> >>> > ISO-8859-1. >>>>>>> >> >>> > That was probably not the best idea though. If we want to >>>>>>> change to >>>>>>> >> >>> > utf-8 >>>>>>> >> >>> > we'd still need to support iso.. for backwards >>>>>>> compatibility. >>>>>>> >> >>> > >>>>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira < >>>>>>> bruno at abstractj.org> wrote: >>>>>>> >> >>> >> >>>>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>>> >> >>> >> >>>>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>>> >> >>> >> > Hello all, >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > I am trying to translate all base theme messages to my >>>>>>> country >>>>>>> >> >>> >> > language, Japanese. And I'd like to contribute them. >>>>>>> Before that >>>>>>> >> >>> >> > work, >>>>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > Currently, the message files (*.properties) are loaded >>>>>>> with >>>>>>> >> >>> >> > ISO-8859-1 >>>>>>> >> >>> >> > encoding. Therefore, it is necessary to convert the >>>>>>> files by >>>>>>> >> >>> >> > 'native2ascii' command beforehand. However we can >>>>>>> directly read >>>>>>> >> >>> >> > the >>>>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or later >>>>>>> because >>>>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >>>>>>> introduced >>>>>>> >> >>> >> > as >>>>>>> >> >>> >> > below. >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > >>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > So, my proposal is supporting the message files with >>>>>>> UTF-8 >>>>>>> >> >>> >> > encoding. >>>>>>> >> >>> >> > I >>>>>>> >> >>> >> > believe that it's very developers/customers friendly. In >>>>>>> >> >>> >> > addition, >>>>>>> >> >>> >> > we >>>>>>> >> >>> >> > can easily review the translated messages on the github >>>>>>> pull >>>>>>> >> >>> >> > request >>>>>>> >> >>> >> > view and so on. What do you think? >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >>>>>>> request. >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > Regards, >>>>>>> >> >>> >> > >>>>>>> >> >>> >> > -- >>>>>>> >> >>> >> > Hiroyuki Wada, >>>>>>> >> >>> >> > Developer, >>>>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>>>> >> >>> >> > _______________________________________________ >>>>>>> >> >>> >> > keycloak-dev mailing list >>>>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>>>> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >> >>> >> >>>>>>> >> >>> >> -- >>>>>>> >> >>> >> >>>>>>> >> >>> >> abstractj >>>>>>> >> >>> >> PGP: 0x84DC9914 >>>>>>> >> >>> >> _______________________________________________ >>>>>>> >> >>> >> 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 >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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/20160715/4b1524b6/attachment-0001.html From sthorger at redhat.com Fri Jul 15 02:14:16 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Jul 2016 08:14:16 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: I'd like the current messages to be converted by the people that have contributed them. They will be able to determine what encoding they prefer to use and also confirm that the conversion has been successful. On 15 July 2016 at 07:59, Hiroyuki Wada wrote: > I mean I'd like to change the message files encoding only. > For example, admin-messages for Russian language is currently written in > ISO-8859-1 encoding. > > > https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/messages/admin-messages_ru.properties > > Can I convert the language messages except for English? > > > 2016?7?15?(?) 14:03 Stian Thorgersen : > >> No, we don't want the theme properties (and other properties files) to be >> utf-8. They should stick with the default encoding used by Java properties >> files. >> >> Messages are a special case, which is why we accepted it for them. >> >> On 14 July 2016 at 13:29, Hiroyuki Wada wrote: >> >>> Thank you for merging the pull request. Could I send a pull request >>> converting to UTF-8 encoding against the theme properties? >>> >>> 2016?7?7?(?) 21:39 Hiroyuki Wada : >>> >>>> Yes. I will send a pull request later! >>>> >>>> 2016?7?7?(?) 21:20 Stian Thorgersen : >>>> >>>>> Are you doing a PR as well? >>>>> >>>>> On 7 July 2016 at 12:33, Hiroyuki Wada wrote: >>>>> >>>>>> Ok. I created a JIRA issue. >>>>>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>>>>> >>>>>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>>>>> >>>>>>> Let's go for it. Please create a JIRA and send PR. Please just use >>>>>>> "# encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter >>>>>>> is just weird if you ask me. >>>>>>> >>>>>>> Thomas: It's optional, defaults to iso-8859-1 and the header will >>>>>>> clearly state that a file uses a different encoding, so I disagree that >>>>>>> there will be any confusion. >>>>>>> >>>>>>> On 6 July 2016 at 12:30, Hiroyuki Wada wrote: >>>>>>> >>>>>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>>>>> wrote: >>>>>>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>>>>>> .properties is >>>>>>>> > still expected to be ISO-8859-1: >>>>>>>> > >>>>>>>> >> Constructing a PropertyResourceBundle instance from an >>>>>>>> InputStream >>>>>>>> >> requires that the input stream be encoded in ISO-8859-1. In that >>>>>>>> case, >>>>>>>> >> characters that cannot be represented in ISO-8859-1 encoding >>>>>>>> must be >>>>>>>> >> represented by Unicode Escapes as defined in section 3.3 of The >>>>>>>> Java? >>>>>>>> >> Language Specification whereas the other constructor which takes >>>>>>>> a Reader >>>>>>>> >> does not have that limitation. >>>>>>>> >>>>>>>> It's a case of using constructor which takes an InputStream. >>>>>>>> It says we can use any encoding when we use the other constructor >>>>>>>> which takes a Reader. >>>>>>>> >>>>>>>> I understand your concern. So what do you think supporting utf-8 >>>>>>>> with >>>>>>>> a header like Stian suggested? >>>>>>>> I think it can avoid confusion because the encoding is noted in the >>>>>>>> file itself... >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> > >>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>>>>> > >>>>>>>> > I understand that Spring allows one to read .properties using any >>>>>>>> encoding, >>>>>>>> > but you need to specify the encoding in Spring configuration >>>>>>>> external to the >>>>>>>> > .properties file. >>>>>>>> > >>>>>>>> > In my opinion it would cause unnecessary confusion amongst >>>>>>>> developers to use >>>>>>>> > any other encoding than the one defined by the official >>>>>>>> documentation for >>>>>>>> > Properties. >>>>>>>> > >>>>>>>> > Best regards, >>>>>>>> > Thomas >>>>>>>> > >>>>>>>> > >>>>>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada < >>>>>>>> wadahiro at gmail.com> wrote: >>>>>>>> >> >>>>>>>> >> I think it was true before Java 1.6 because Java standard library >>>>>>>> >> (java.util.ResourceBundle or java.util.Properties) only supported >>>>>>>> >> ISO-8859-1 encoding file. >>>>>>>> >> But they support any encoding after Java 1.6. There are some >>>>>>>> >> frameworks which can read .properties with any encoding. For >>>>>>>> example, >>>>>>>> >> Spring Framework can read .properties with any encoding. I think >>>>>>>> it's >>>>>>>> >> very useful to read UTF-8 directly for multibyte language >>>>>>>> country. >>>>>>>> >> >>>>>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>>>>> >> wrote: >>>>>>>> >> > Please correct me if I am wrong, but I have been under the >>>>>>>> impression >>>>>>>> >> > that >>>>>>>> >> > Java .properties files should always use encoding ISO-8859-1. >>>>>>>> Characters >>>>>>>> >> > not >>>>>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make >>>>>>>> things >>>>>>>> >> > confusing to developers if another encoding is used here >>>>>>>> instead? >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>>>>> >> > >>>>>>>> >> > If alternate encodings are desired how about supporting the >>>>>>>> XML format >>>>>>>> >> > of >>>>>>>> >> > Properties? >>>>>>>> >> > >>>>>>>> >> > Best regards, >>>>>>>> >> > Thomas >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>>>>> sthorger at redhat.com> >>>>>>>> >> > wrote: >>>>>>>> >> >> >>>>>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >>>>>>>> co-exist. >>>>>>>> >> >> >>>>>>>> >> >> We can allow specifying the encoding in a comment on the >>>>>>>> first line >>>>>>>> >> >> like >>>>>>>> >> >> this: >>>>>>>> >> >> >>>>>>>> >> >> # encoding=utf-8 >>>>>>>> >> >> key=value >>>>>>>> >> >> >>>>>>>> >> >> # encoding=iso-8859-1 >>>>>>>> >> >> key=value >>>>>>>> >> >> >>>>>>>> >> >> If the first line in the file doesn't contain the comment >>>>>>>> with the >>>>>>>> >> >> encoding then we should default to iso-8859-1 for backwards >>>>>>>> >> >> compatibility >>>>>>>> >> >> >>>>>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada >>>>>>>> wrote: >>>>>>>> >> >>> >>>>>>>> >> >>> Thanks for your comment. >>>>>>>> >> >>> >>>>>>>> >> >>> > If we want to change to utf-8 we'd still need to support >>>>>>>> iso.. for >>>>>>>> >> >>> > backwards compatibility. >>>>>>>> >> >>> >>>>>>>> >> >>> If we change to UTF-8, we can still read unicode codepoint >>>>>>>> like >>>>>>>> >> >>> '\u00e8'. >>>>>>>> >> >>> There is an incompatibility when non-ascii characters are >>>>>>>> used in >>>>>>>> >> >>> message properties. >>>>>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please refer >>>>>>>> codepage >>>>>>>> >> >>> layout: >>>>>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>>>>> >> >>> >>>>>>>> >> >>> I think the non-ascii characters might be used in French >>>>>>>> messages like >>>>>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>>>>> compatibility. >>>>>>>> >> >>> To support this, I think we can add a property like >>>>>>>> "messageEncoding" >>>>>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>>>>> >> >>> >>>>>>>> >> >>> "theme": { >>>>>>>> >> >>> "staticMaxAge": 2592000, >>>>>>>> >> >>> "cacheTemplates": true, >>>>>>>> >> >>> "cacheThemes": true, >>>>>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>>>>> >> >>> "folder": { >>>>>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>>>>> >> >>> } >>>>>>>> >> >>> }, >>>>>>>> >> >>> >>>>>>>> >> >>> Regards, >>>>>>>> >> >>> >>>>>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>>>>> >> >>> >>>>>>>> >> >>> wrote: >>>>>>>> >> >>> > We have in the past discussed this and decided to stick >>>>>>>> with >>>>>>>> >> >>> > ISO-8859-1. >>>>>>>> >> >>> > That was probably not the best idea though. If we want to >>>>>>>> change to >>>>>>>> >> >>> > utf-8 >>>>>>>> >> >>> > we'd still need to support iso.. for backwards >>>>>>>> compatibility. >>>>>>>> >> >>> > >>>>>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira < >>>>>>>> bruno at abstractj.org> wrote: >>>>>>>> >> >>> >> >>>>>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>>>> >> >>> >> >>>>>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>>>> >> >>> >> > Hello all, >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > I am trying to translate all base theme messages to my >>>>>>>> country >>>>>>>> >> >>> >> > language, Japanese. And I'd like to contribute them. >>>>>>>> Before that >>>>>>>> >> >>> >> > work, >>>>>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > Currently, the message files (*.properties) are loaded >>>>>>>> with >>>>>>>> >> >>> >> > ISO-8859-1 >>>>>>>> >> >>> >> > encoding. Therefore, it is necessary to convert the >>>>>>>> files by >>>>>>>> >> >>> >> > 'native2ascii' command beforehand. However we can >>>>>>>> directly read >>>>>>>> >> >>> >> > the >>>>>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or later >>>>>>>> because >>>>>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >>>>>>>> introduced >>>>>>>> >> >>> >> > as >>>>>>>> >> >>> >> > below. >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > >>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > So, my proposal is supporting the message files with >>>>>>>> UTF-8 >>>>>>>> >> >>> >> > encoding. >>>>>>>> >> >>> >> > I >>>>>>>> >> >>> >> > believe that it's very developers/customers friendly. In >>>>>>>> >> >>> >> > addition, >>>>>>>> >> >>> >> > we >>>>>>>> >> >>> >> > can easily review the translated messages on the github >>>>>>>> pull >>>>>>>> >> >>> >> > request >>>>>>>> >> >>> >> > view and so on. What do you think? >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >>>>>>>> request. >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > Regards, >>>>>>>> >> >>> >> > >>>>>>>> >> >>> >> > -- >>>>>>>> >> >>> >> > Hiroyuki Wada, >>>>>>>> >> >>> >> > Developer, >>>>>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>>>>> >> >>> >> > _______________________________________________ >>>>>>>> >> >>> >> > keycloak-dev mailing list >>>>>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>>>>> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> >> >>> >> >>>>>>>> >> >>> >> -- >>>>>>>> >> >>> >> >>>>>>>> >> >>> >> abstractj >>>>>>>> >> >>> >> PGP: 0x84DC9914 >>>>>>>> >> >>> >> _______________________________________________ >>>>>>>> >> >>> >> 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 >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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/20160715/95dc9b27/attachment-0001.html From sthorger at redhat.com Fri Jul 15 02:14:55 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Jul 2016 08:14:55 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: BTW do you have a reliable way to convert the files? I've tried various tools, but none worked for me. On 15 July 2016 at 08:14, Stian Thorgersen wrote: > I'd like the current messages to be converted by the people that have > contributed them. They will be able to determine what encoding they prefer > to use and also confirm that the conversion has been successful. > > On 15 July 2016 at 07:59, Hiroyuki Wada wrote: > >> I mean I'd like to change the message files encoding only. >> For example, admin-messages for Russian language is currently written in >> ISO-8859-1 encoding. >> >> >> https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/messages/admin-messages_ru.properties >> >> Can I convert the language messages except for English? >> >> >> 2016?7?15?(?) 14:03 Stian Thorgersen : >> >>> No, we don't want the theme properties (and other properties files) to >>> be utf-8. They should stick with the default encoding used by Java >>> properties files. >>> >>> Messages are a special case, which is why we accepted it for them. >>> >>> On 14 July 2016 at 13:29, Hiroyuki Wada wrote: >>> >>>> Thank you for merging the pull request. Could I send a pull request >>>> converting to UTF-8 encoding against the theme properties? >>>> >>>> 2016?7?7?(?) 21:39 Hiroyuki Wada : >>>> >>>>> Yes. I will send a pull request later! >>>>> >>>>> 2016?7?7?(?) 21:20 Stian Thorgersen : >>>>> >>>>>> Are you doing a PR as well? >>>>>> >>>>>> On 7 July 2016 at 12:33, Hiroyuki Wada wrote: >>>>>> >>>>>>> Ok. I created a JIRA issue. >>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>>>>>> >>>>>>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>>>>>> >>>>>>>> Let's go for it. Please create a JIRA and send PR. Please just use >>>>>>>> "# encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter >>>>>>>> is just weird if you ask me. >>>>>>>> >>>>>>>> Thomas: It's optional, defaults to iso-8859-1 and the header will >>>>>>>> clearly state that a file uses a different encoding, so I disagree that >>>>>>>> there will be any confusion. >>>>>>>> >>>>>>>> On 6 July 2016 at 12:30, Hiroyuki Wada wrote: >>>>>>>> >>>>>>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>>>>>> wrote: >>>>>>>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>>>>>>> .properties is >>>>>>>>> > still expected to be ISO-8859-1: >>>>>>>>> > >>>>>>>>> >> Constructing a PropertyResourceBundle instance from an >>>>>>>>> InputStream >>>>>>>>> >> requires that the input stream be encoded in ISO-8859-1. In >>>>>>>>> that case, >>>>>>>>> >> characters that cannot be represented in ISO-8859-1 encoding >>>>>>>>> must be >>>>>>>>> >> represented by Unicode Escapes as defined in section 3.3 of The >>>>>>>>> Java? >>>>>>>>> >> Language Specification whereas the other constructor which >>>>>>>>> takes a Reader >>>>>>>>> >> does not have that limitation. >>>>>>>>> >>>>>>>>> It's a case of using constructor which takes an InputStream. >>>>>>>>> It says we can use any encoding when we use the other constructor >>>>>>>>> which takes a Reader. >>>>>>>>> >>>>>>>>> I understand your concern. So what do you think supporting utf-8 >>>>>>>>> with >>>>>>>>> a header like Stian suggested? >>>>>>>>> I think it can avoid confusion because the encoding is noted in the >>>>>>>>> file itself... >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> > >>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>>>>>> > >>>>>>>>> > I understand that Spring allows one to read .properties using >>>>>>>>> any encoding, >>>>>>>>> > but you need to specify the encoding in Spring configuration >>>>>>>>> external to the >>>>>>>>> > .properties file. >>>>>>>>> > >>>>>>>>> > In my opinion it would cause unnecessary confusion amongst >>>>>>>>> developers to use >>>>>>>>> > any other encoding than the one defined by the official >>>>>>>>> documentation for >>>>>>>>> > Properties. >>>>>>>>> > >>>>>>>>> > Best regards, >>>>>>>>> > Thomas >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada < >>>>>>>>> wadahiro at gmail.com> wrote: >>>>>>>>> >> >>>>>>>>> >> I think it was true before Java 1.6 because Java standard >>>>>>>>> library >>>>>>>>> >> (java.util.ResourceBundle or java.util.Properties) only >>>>>>>>> supported >>>>>>>>> >> ISO-8859-1 encoding file. >>>>>>>>> >> But they support any encoding after Java 1.6. There are some >>>>>>>>> >> frameworks which can read .properties with any encoding. For >>>>>>>>> example, >>>>>>>>> >> Spring Framework can read .properties with any encoding. I >>>>>>>>> think it's >>>>>>>>> >> very useful to read UTF-8 directly for multibyte language >>>>>>>>> country. >>>>>>>>> >> >>>>>>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>>>>>> >> wrote: >>>>>>>>> >> > Please correct me if I am wrong, but I have been under the >>>>>>>>> impression >>>>>>>>> >> > that >>>>>>>>> >> > Java .properties files should always use encoding ISO-8859-1. >>>>>>>>> Characters >>>>>>>>> >> > not >>>>>>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it make >>>>>>>>> things >>>>>>>>> >> > confusing to developers if another encoding is used here >>>>>>>>> instead? >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>>>>>> >> > >>>>>>>>> >> > If alternate encodings are desired how about supporting the >>>>>>>>> XML format >>>>>>>>> >> > of >>>>>>>>> >> > Properties? >>>>>>>>> >> > >>>>>>>>> >> > Best regards, >>>>>>>>> >> > Thomas >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>>>>>> sthorger at redhat.com> >>>>>>>>> >> > wrote: >>>>>>>>> >> >> >>>>>>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >>>>>>>>> co-exist. >>>>>>>>> >> >> >>>>>>>>> >> >> We can allow specifying the encoding in a comment on the >>>>>>>>> first line >>>>>>>>> >> >> like >>>>>>>>> >> >> this: >>>>>>>>> >> >> >>>>>>>>> >> >> # encoding=utf-8 >>>>>>>>> >> >> key=value >>>>>>>>> >> >> >>>>>>>>> >> >> # encoding=iso-8859-1 >>>>>>>>> >> >> key=value >>>>>>>>> >> >> >>>>>>>>> >> >> If the first line in the file doesn't contain the comment >>>>>>>>> with the >>>>>>>>> >> >> encoding then we should default to iso-8859-1 for backwards >>>>>>>>> >> >> compatibility >>>>>>>>> >> >> >>>>>>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada >>>>>>>>> wrote: >>>>>>>>> >> >>> >>>>>>>>> >> >>> Thanks for your comment. >>>>>>>>> >> >>> >>>>>>>>> >> >>> > If we want to change to utf-8 we'd still need to support >>>>>>>>> iso.. for >>>>>>>>> >> >>> > backwards compatibility. >>>>>>>>> >> >>> >>>>>>>>> >> >>> If we change to UTF-8, we can still read unicode codepoint >>>>>>>>> like >>>>>>>>> >> >>> '\u00e8'. >>>>>>>>> >> >>> There is an incompatibility when non-ascii characters are >>>>>>>>> used in >>>>>>>>> >> >>> message properties. >>>>>>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please >>>>>>>>> refer codepage >>>>>>>>> >> >>> layout: >>>>>>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>>>>>> >> >>> >>>>>>>>> >> >>> I think the non-ascii characters might be used in French >>>>>>>>> messages like >>>>>>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>>>>>> compatibility. >>>>>>>>> >> >>> To support this, I think we can add a property like >>>>>>>>> "messageEncoding" >>>>>>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>>>>>> >> >>> >>>>>>>>> >> >>> "theme": { >>>>>>>>> >> >>> "staticMaxAge": 2592000, >>>>>>>>> >> >>> "cacheTemplates": true, >>>>>>>>> >> >>> "cacheThemes": true, >>>>>>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>>>>>> >> >>> "folder": { >>>>>>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>>>>>> >> >>> } >>>>>>>>> >> >>> }, >>>>>>>>> >> >>> >>>>>>>>> >> >>> Regards, >>>>>>>>> >> >>> >>>>>>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>>>>>> >> >>> >>>>>>>>> >> >>> wrote: >>>>>>>>> >> >>> > We have in the past discussed this and decided to stick >>>>>>>>> with >>>>>>>>> >> >>> > ISO-8859-1. >>>>>>>>> >> >>> > That was probably not the best idea though. If we want to >>>>>>>>> change to >>>>>>>>> >> >>> > utf-8 >>>>>>>>> >> >>> > we'd still need to support iso.. for backwards >>>>>>>>> compatibility. >>>>>>>>> >> >>> > >>>>>>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira < >>>>>>>>> bruno at abstractj.org> wrote: >>>>>>>>> >> >>> >> >>>>>>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>>>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>>>>> >> >>> >> >>>>>>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>>>>> >> >>> >> > Hello all, >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > I am trying to translate all base theme messages to my >>>>>>>>> country >>>>>>>>> >> >>> >> > language, Japanese. And I'd like to contribute them. >>>>>>>>> Before that >>>>>>>>> >> >>> >> > work, >>>>>>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > Currently, the message files (*.properties) are loaded >>>>>>>>> with >>>>>>>>> >> >>> >> > ISO-8859-1 >>>>>>>>> >> >>> >> > encoding. Therefore, it is necessary to convert the >>>>>>>>> files by >>>>>>>>> >> >>> >> > 'native2ascii' command beforehand. However we can >>>>>>>>> directly read >>>>>>>>> >> >>> >> > the >>>>>>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or >>>>>>>>> later because >>>>>>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method was >>>>>>>>> introduced >>>>>>>>> >> >>> >> > as >>>>>>>>> >> >>> >> > below. >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > >>>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > So, my proposal is supporting the message files with >>>>>>>>> UTF-8 >>>>>>>>> >> >>> >> > encoding. >>>>>>>>> >> >>> >> > I >>>>>>>>> >> >>> >> > believe that it's very developers/customers friendly. >>>>>>>>> In >>>>>>>>> >> >>> >> > addition, >>>>>>>>> >> >>> >> > we >>>>>>>>> >> >>> >> > can easily review the translated messages on the >>>>>>>>> github pull >>>>>>>>> >> >>> >> > request >>>>>>>>> >> >>> >> > view and so on. What do you think? >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a pull >>>>>>>>> request. >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > Regards, >>>>>>>>> >> >>> >> > >>>>>>>>> >> >>> >> > -- >>>>>>>>> >> >>> >> > Hiroyuki Wada, >>>>>>>>> >> >>> >> > Developer, >>>>>>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>>>>>> >> >>> >> > _______________________________________________ >>>>>>>>> >> >>> >> > keycloak-dev mailing list >>>>>>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>>>>>> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>> >> >>> >> >>>>>>>>> >> >>> >> -- >>>>>>>>> >> >>> >> >>>>>>>>> >> >>> >> abstractj >>>>>>>>> >> >>> >> PGP: 0x84DC9914 >>>>>>>>> >> >>> >> _______________________________________________ >>>>>>>>> >> >>> >> 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 >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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/20160715/98e7fa42/attachment-0001.html From wadahiro at gmail.com Fri Jul 15 02:57:14 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Fri, 15 Jul 2016 06:57:14 +0000 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: > BTW do you have a reliable way to convert the files? I've tried various > tools, but none worked for me. > Yes, we can use native2ascii command. Example: native2ascii -encoding UTF-8 -reverse > On 15 July 2016 at 08:14, Stian Thorgersen wrote: > >> I'd like the current messages to be converted by the people that have >> contributed them. They will be able to determine what encoding they prefer >> to use and also confirm that the conversion has been successful. >> >> On 15 July 2016 at 07:59, Hiroyuki Wada wrote: >> >>> I mean I'd like to change the message files encoding only. >>> For example, admin-messages for Russian language is currently written in >>> ISO-8859-1 encoding. >>> >>> >>> https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/messages/admin-messages_ru.properties >>> >>> Can I convert the language messages except for English? >>> >>> >>> 2016?7?15?(?) 14:03 Stian Thorgersen : >>> >>>> No, we don't want the theme properties (and other properties files) to >>>> be utf-8. They should stick with the default encoding used by Java >>>> properties files. >>>> >>>> Messages are a special case, which is why we accepted it for them. >>>> >>>> On 14 July 2016 at 13:29, Hiroyuki Wada wrote: >>>> >>>>> Thank you for merging the pull request. Could I send a pull request >>>>> converting to UTF-8 encoding against the theme properties? >>>>> >>>>> 2016?7?7?(?) 21:39 Hiroyuki Wada : >>>>> >>>>>> Yes. I will send a pull request later! >>>>>> >>>>>> 2016?7?7?(?) 21:20 Stian Thorgersen : >>>>>> >>>>>>> Are you doing a PR as well? >>>>>>> >>>>>>> On 7 July 2016 at 12:33, Hiroyuki Wada wrote: >>>>>>> >>>>>>>> Ok. I created a JIRA issue. >>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>>>>>>> >>>>>>>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>>>>>>> >>>>>>>>> Let's go for it. Please create a JIRA and send PR. Please just use >>>>>>>>> "# encoding: utf-8" and not "# -*- coding: utf-8 -*-". The latter >>>>>>>>> is just weird if you ask me. >>>>>>>>> >>>>>>>>> Thomas: It's optional, defaults to iso-8859-1 and the header will >>>>>>>>> clearly state that a file uses a different encoding, so I disagree that >>>>>>>>> there will be any confusion. >>>>>>>>> >>>>>>>>> On 6 July 2016 at 12:30, Hiroyuki Wada wrote: >>>>>>>>> >>>>>>>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>>>>>>> wrote: >>>>>>>>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>>>>>>>> .properties is >>>>>>>>>> > still expected to be ISO-8859-1: >>>>>>>>>> > >>>>>>>>>> >> Constructing a PropertyResourceBundle instance from an >>>>>>>>>> InputStream >>>>>>>>>> >> requires that the input stream be encoded in ISO-8859-1. In >>>>>>>>>> that case, >>>>>>>>>> >> characters that cannot be represented in ISO-8859-1 encoding >>>>>>>>>> must be >>>>>>>>>> >> represented by Unicode Escapes as defined in section 3.3 of >>>>>>>>>> The Java? >>>>>>>>>> >> Language Specification whereas the other constructor which >>>>>>>>>> takes a Reader >>>>>>>>>> >> does not have that limitation. >>>>>>>>>> >>>>>>>>>> It's a case of using constructor which takes an InputStream. >>>>>>>>>> It says we can use any encoding when we use the other constructor >>>>>>>>>> which takes a Reader. >>>>>>>>>> >>>>>>>>>> I understand your concern. So what do you think supporting utf-8 >>>>>>>>>> with >>>>>>>>>> a header like Stian suggested? >>>>>>>>>> I think it can avoid confusion because the encoding is noted in >>>>>>>>>> the >>>>>>>>>> file itself... >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>>>>>>> > >>>>>>>>>> > I understand that Spring allows one to read .properties using >>>>>>>>>> any encoding, >>>>>>>>>> > but you need to specify the encoding in Spring configuration >>>>>>>>>> external to the >>>>>>>>>> > .properties file. >>>>>>>>>> > >>>>>>>>>> > In my opinion it would cause unnecessary confusion amongst >>>>>>>>>> developers to use >>>>>>>>>> > any other encoding than the one defined by the official >>>>>>>>>> documentation for >>>>>>>>>> > Properties. >>>>>>>>>> > >>>>>>>>>> > Best regards, >>>>>>>>>> > Thomas >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada < >>>>>>>>>> wadahiro at gmail.com> wrote: >>>>>>>>>> >> >>>>>>>>>> >> I think it was true before Java 1.6 because Java standard >>>>>>>>>> library >>>>>>>>>> >> (java.util.ResourceBundle or java.util.Properties) only >>>>>>>>>> supported >>>>>>>>>> >> ISO-8859-1 encoding file. >>>>>>>>>> >> But they support any encoding after Java 1.6. There are some >>>>>>>>>> >> frameworks which can read .properties with any encoding. For >>>>>>>>>> example, >>>>>>>>>> >> Spring Framework can read .properties with any encoding. I >>>>>>>>>> think it's >>>>>>>>>> >> very useful to read UTF-8 directly for multibyte language >>>>>>>>>> country. >>>>>>>>>> >> >>>>>>>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>>>>>>> >> wrote: >>>>>>>>>> >> > Please correct me if I am wrong, but I have been under the >>>>>>>>>> impression >>>>>>>>>> >> > that >>>>>>>>>> >> > Java .properties files should always use encoding >>>>>>>>>> ISO-8859-1. Characters >>>>>>>>>> >> > not >>>>>>>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it >>>>>>>>>> make things >>>>>>>>>> >> > confusing to developers if another encoding is used here >>>>>>>>>> instead? >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>>>>>>> >> > >>>>>>>>>> >> > If alternate encodings are desired how about supporting the >>>>>>>>>> XML format >>>>>>>>>> >> > of >>>>>>>>>> >> > Properties? >>>>>>>>>> >> > >>>>>>>>>> >> > Best regards, >>>>>>>>>> >> > Thomas >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>>>>>>> sthorger at redhat.com> >>>>>>>>>> >> > wrote: >>>>>>>>>> >> >> >>>>>>>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able to >>>>>>>>>> co-exist. >>>>>>>>>> >> >> >>>>>>>>>> >> >> We can allow specifying the encoding in a comment on the >>>>>>>>>> first line >>>>>>>>>> >> >> like >>>>>>>>>> >> >> this: >>>>>>>>>> >> >> >>>>>>>>>> >> >> # encoding=utf-8 >>>>>>>>>> >> >> key=value >>>>>>>>>> >> >> >>>>>>>>>> >> >> # encoding=iso-8859-1 >>>>>>>>>> >> >> key=value >>>>>>>>>> >> >> >>>>>>>>>> >> >> If the first line in the file doesn't contain the comment >>>>>>>>>> with the >>>>>>>>>> >> >> encoding then we should default to iso-8859-1 for backwards >>>>>>>>>> >> >> compatibility >>>>>>>>>> >> >> >>>>>>>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada >>>>>>>>>> wrote: >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> Thanks for your comment. >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> > If we want to change to utf-8 we'd still need to support >>>>>>>>>> iso.. for >>>>>>>>>> >> >>> > backwards compatibility. >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> If we change to UTF-8, we can still read unicode codepoint >>>>>>>>>> like >>>>>>>>>> >> >>> '\u00e8'. >>>>>>>>>> >> >>> There is an incompatibility when non-ascii characters are >>>>>>>>>> used in >>>>>>>>>> >> >>> message properties. >>>>>>>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please >>>>>>>>>> refer codepage >>>>>>>>>> >> >>> layout: >>>>>>>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> I think the non-ascii characters might be used in French >>>>>>>>>> messages like >>>>>>>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>>>>>>> compatibility. >>>>>>>>>> >> >>> To support this, I think we can add a property like >>>>>>>>>> "messageEncoding" >>>>>>>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> "theme": { >>>>>>>>>> >> >>> "staticMaxAge": 2592000, >>>>>>>>>> >> >>> "cacheTemplates": true, >>>>>>>>>> >> >>> "cacheThemes": true, >>>>>>>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>>>>>>> >> >>> "folder": { >>>>>>>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>>>>>>> >> >>> } >>>>>>>>>> >> >>> }, >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> Regards, >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> wrote: >>>>>>>>>> >> >>> > We have in the past discussed this and decided to stick >>>>>>>>>> with >>>>>>>>>> >> >>> > ISO-8859-1. >>>>>>>>>> >> >>> > That was probably not the best idea though. If we want >>>>>>>>>> to change to >>>>>>>>>> >> >>> > utf-8 >>>>>>>>>> >> >>> > we'd still need to support iso.. for backwards >>>>>>>>>> compatibility. >>>>>>>>>> >> >>> > >>>>>>>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira < >>>>>>>>>> bruno at abstractj.org> wrote: >>>>>>>>>> >> >>> >> >>>>>>>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>>>>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>>>>>> >> >>> >> >>>>>>>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>>>>>> >> >>> >> > Hello all, >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > I am trying to translate all base theme messages to >>>>>>>>>> my country >>>>>>>>>> >> >>> >> > language, Japanese. And I'd like to contribute them. >>>>>>>>>> Before that >>>>>>>>>> >> >>> >> > work, >>>>>>>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > Currently, the message files (*.properties) are >>>>>>>>>> loaded with >>>>>>>>>> >> >>> >> > ISO-8859-1 >>>>>>>>>> >> >>> >> > encoding. Therefore, it is necessary to convert the >>>>>>>>>> files by >>>>>>>>>> >> >>> >> > 'native2ascii' command beforehand. However we can >>>>>>>>>> directly read >>>>>>>>>> >> >>> >> > the >>>>>>>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or >>>>>>>>>> later because >>>>>>>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method >>>>>>>>>> was introduced >>>>>>>>>> >> >>> >> > as >>>>>>>>>> >> >>> >> > below. >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > >>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > So, my proposal is supporting the message files with >>>>>>>>>> UTF-8 >>>>>>>>>> >> >>> >> > encoding. >>>>>>>>>> >> >>> >> > I >>>>>>>>>> >> >>> >> > believe that it's very developers/customers friendly. >>>>>>>>>> In >>>>>>>>>> >> >>> >> > addition, >>>>>>>>>> >> >>> >> > we >>>>>>>>>> >> >>> >> > can easily review the translated messages on the >>>>>>>>>> github pull >>>>>>>>>> >> >>> >> > request >>>>>>>>>> >> >>> >> > view and so on. What do you think? >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a >>>>>>>>>> pull request. >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > Regards, >>>>>>>>>> >> >>> >> > >>>>>>>>>> >> >>> >> > -- >>>>>>>>>> >> >>> >> > Hiroyuki Wada, >>>>>>>>>> >> >>> >> > Developer, >>>>>>>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>>>>>>> >> >>> >> > _______________________________________________ >>>>>>>>>> >> >>> >> > keycloak-dev mailing list >>>>>>>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>>>>>>> >> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>> >> >>> >> >>>>>>>>>> >> >>> >> -- >>>>>>>>>> >> >>> >> >>>>>>>>>> >> >>> >> abstractj >>>>>>>>>> >> >>> >> PGP: 0x84DC9914 >>>>>>>>>> >> >>> >> _______________________________________________ >>>>>>>>>> >> >>> >> 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 >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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/20160715/6516b3da/attachment-0001.html From thomas.raehalme at aitiofinland.com Fri Jul 15 03:04:00 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Fri, 15 Jul 2016 10:04:00 +0300 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: iconv has been a good tool to convert files from one encoding to another. Best regards, Thomas On Jul 15, 2016 09:57, "Hiroyuki Wada" wrote: > > BTW do you have a reliable way to convert the files? I've tried various >> tools, but none worked for me. >> > > Yes, we can use native2ascii command. > > Example: > native2ascii -encoding UTF-8 -reverse > > > > >> On 15 July 2016 at 08:14, Stian Thorgersen wrote: >> >>> I'd like the current messages to be converted by the people that have >>> contributed them. They will be able to determine what encoding they prefer >>> to use and also confirm that the conversion has been successful. >>> >>> On 15 July 2016 at 07:59, Hiroyuki Wada wrote: >>> >>>> I mean I'd like to change the message files encoding only. >>>> For example, admin-messages for Russian language is currently written >>>> in ISO-8859-1 encoding. >>>> >>>> >>>> https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/messages/admin-messages_ru.properties >>>> >>>> Can I convert the language messages except for English? >>>> >>>> >>>> 2016?7?15?(?) 14:03 Stian Thorgersen : >>>> >>>>> No, we don't want the theme properties (and other properties files) to >>>>> be utf-8. They should stick with the default encoding used by Java >>>>> properties files. >>>>> >>>>> Messages are a special case, which is why we accepted it for them. >>>>> >>>>> On 14 July 2016 at 13:29, Hiroyuki Wada wrote: >>>>> >>>>>> Thank you for merging the pull request. Could I send a pull request >>>>>> converting to UTF-8 encoding against the theme properties? >>>>>> >>>>>> 2016?7?7?(?) 21:39 Hiroyuki Wada : >>>>>> >>>>>>> Yes. I will send a pull request later! >>>>>>> >>>>>>> 2016?7?7?(?) 21:20 Stian Thorgersen : >>>>>>> >>>>>>>> Are you doing a PR as well? >>>>>>>> >>>>>>>> On 7 July 2016 at 12:33, Hiroyuki Wada wrote: >>>>>>>> >>>>>>>>> Ok. I created a JIRA issue. >>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>>>>>>>> >>>>>>>>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>>>>>>>> >>>>>>>>>> Let's go for it. Please create a JIRA and send PR. Please just >>>>>>>>>> use "# encoding: utf-8" and not "# -*- coding: utf-8 -*-". The >>>>>>>>>> latter is just weird if you ask me. >>>>>>>>>> >>>>>>>>>> Thomas: It's optional, defaults to iso-8859-1 and the header will >>>>>>>>>> clearly state that a file uses a different encoding, so I disagree that >>>>>>>>>> there will be any confusion. >>>>>>>>>> >>>>>>>>>> On 6 July 2016 at 12:30, Hiroyuki Wada >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>>>>>>>> wrote: >>>>>>>>>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>>>>>>>>> .properties is >>>>>>>>>>> > still expected to be ISO-8859-1: >>>>>>>>>>> > >>>>>>>>>>> >> Constructing a PropertyResourceBundle instance from an >>>>>>>>>>> InputStream >>>>>>>>>>> >> requires that the input stream be encoded in ISO-8859-1. In >>>>>>>>>>> that case, >>>>>>>>>>> >> characters that cannot be represented in ISO-8859-1 encoding >>>>>>>>>>> must be >>>>>>>>>>> >> represented by Unicode Escapes as defined in section 3.3 of >>>>>>>>>>> The Java? >>>>>>>>>>> >> Language Specification whereas the other constructor which >>>>>>>>>>> takes a Reader >>>>>>>>>>> >> does not have that limitation. >>>>>>>>>>> >>>>>>>>>>> It's a case of using constructor which takes an InputStream. >>>>>>>>>>> It says we can use any encoding when we use the other constructor >>>>>>>>>>> which takes a Reader. >>>>>>>>>>> >>>>>>>>>>> I understand your concern. So what do you think supporting utf-8 >>>>>>>>>>> with >>>>>>>>>>> a header like Stian suggested? >>>>>>>>>>> I think it can avoid confusion because the encoding is noted in >>>>>>>>>>> the >>>>>>>>>>> file itself... >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>>>>>>>> > >>>>>>>>>>> > I understand that Spring allows one to read .properties using >>>>>>>>>>> any encoding, >>>>>>>>>>> > but you need to specify the encoding in Spring configuration >>>>>>>>>>> external to the >>>>>>>>>>> > .properties file. >>>>>>>>>>> > >>>>>>>>>>> > In my opinion it would cause unnecessary confusion amongst >>>>>>>>>>> developers to use >>>>>>>>>>> > any other encoding than the one defined by the official >>>>>>>>>>> documentation for >>>>>>>>>>> > Properties. >>>>>>>>>>> > >>>>>>>>>>> > Best regards, >>>>>>>>>>> > Thomas >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada < >>>>>>>>>>> wadahiro at gmail.com> wrote: >>>>>>>>>>> >> >>>>>>>>>>> >> I think it was true before Java 1.6 because Java standard >>>>>>>>>>> library >>>>>>>>>>> >> (java.util.ResourceBundle or java.util.Properties) only >>>>>>>>>>> supported >>>>>>>>>>> >> ISO-8859-1 encoding file. >>>>>>>>>>> >> But they support any encoding after Java 1.6. There are some >>>>>>>>>>> >> frameworks which can read .properties with any encoding. For >>>>>>>>>>> example, >>>>>>>>>>> >> Spring Framework can read .properties with any encoding. I >>>>>>>>>>> think it's >>>>>>>>>>> >> very useful to read UTF-8 directly for multibyte language >>>>>>>>>>> country. >>>>>>>>>>> >> >>>>>>>>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>>>>>>>> >> wrote: >>>>>>>>>>> >> > Please correct me if I am wrong, but I have been under the >>>>>>>>>>> impression >>>>>>>>>>> >> > that >>>>>>>>>>> >> > Java .properties files should always use encoding >>>>>>>>>>> ISO-8859-1. Characters >>>>>>>>>>> >> > not >>>>>>>>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it >>>>>>>>>>> make things >>>>>>>>>>> >> > confusing to developers if another encoding is used here >>>>>>>>>>> instead? >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>>>>>>>> >> > >>>>>>>>>>> >> > If alternate encodings are desired how about supporting the >>>>>>>>>>> XML format >>>>>>>>>>> >> > of >>>>>>>>>>> >> > Properties? >>>>>>>>>>> >> > >>>>>>>>>>> >> > Best regards, >>>>>>>>>>> >> > Thomas >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>>>>>>>> sthorger at redhat.com> >>>>>>>>>>> >> > wrote: >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able >>>>>>>>>>> to co-exist. >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> We can allow specifying the encoding in a comment on the >>>>>>>>>>> first line >>>>>>>>>>> >> >> like >>>>>>>>>>> >> >> this: >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> # encoding=utf-8 >>>>>>>>>>> >> >> key=value >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> # encoding=iso-8859-1 >>>>>>>>>>> >> >> key=value >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> If the first line in the file doesn't contain the comment >>>>>>>>>>> with the >>>>>>>>>>> >> >> encoding then we should default to iso-8859-1 for backwards >>>>>>>>>>> >> >> compatibility >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada >>>>>>>>>>> wrote: >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> Thanks for your comment. >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> > If we want to change to utf-8 we'd still need to >>>>>>>>>>> support iso.. for >>>>>>>>>>> >> >>> > backwards compatibility. >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> If we change to UTF-8, we can still read unicode >>>>>>>>>>> codepoint like >>>>>>>>>>> >> >>> '\u00e8'. >>>>>>>>>>> >> >>> There is an incompatibility when non-ascii characters are >>>>>>>>>>> used in >>>>>>>>>>> >> >>> message properties. >>>>>>>>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please >>>>>>>>>>> refer codepage >>>>>>>>>>> >> >>> layout: >>>>>>>>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> I think the non-ascii characters might be used in French >>>>>>>>>>> messages like >>>>>>>>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>>>>>>>> compatibility. >>>>>>>>>>> >> >>> To support this, I think we can add a property like >>>>>>>>>>> "messageEncoding" >>>>>>>>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> "theme": { >>>>>>>>>>> >> >>> "staticMaxAge": 2592000, >>>>>>>>>>> >> >>> "cacheTemplates": true, >>>>>>>>>>> >> >>> "cacheThemes": true, >>>>>>>>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>>>>>>>> >> >>> "folder": { >>>>>>>>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>>>>>>>> >> >>> } >>>>>>>>>>> >> >>> }, >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> Regards, >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> wrote: >>>>>>>>>>> >> >>> > We have in the past discussed this and decided to stick >>>>>>>>>>> with >>>>>>>>>>> >> >>> > ISO-8859-1. >>>>>>>>>>> >> >>> > That was probably not the best idea though. If we want >>>>>>>>>>> to change to >>>>>>>>>>> >> >>> > utf-8 >>>>>>>>>>> >> >>> > we'd still need to support iso.. for backwards >>>>>>>>>>> compatibility. >>>>>>>>>>> >> >>> > >>>>>>>>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira < >>>>>>>>>>> bruno at abstractj.org> wrote: >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>>>>>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>>>>>>> >> >>> >> > Hello all, >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > I am trying to translate all base theme messages to >>>>>>>>>>> my country >>>>>>>>>>> >> >>> >> > language, Japanese. And I'd like to contribute them. >>>>>>>>>>> Before that >>>>>>>>>>> >> >>> >> > work, >>>>>>>>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > Currently, the message files (*.properties) are >>>>>>>>>>> loaded with >>>>>>>>>>> >> >>> >> > ISO-8859-1 >>>>>>>>>>> >> >>> >> > encoding. Therefore, it is necessary to convert the >>>>>>>>>>> files by >>>>>>>>>>> >> >>> >> > 'native2ascii' command beforehand. However we can >>>>>>>>>>> directly read >>>>>>>>>>> >> >>> >> > the >>>>>>>>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or >>>>>>>>>>> later because >>>>>>>>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method >>>>>>>>>>> was introduced >>>>>>>>>>> >> >>> >> > as >>>>>>>>>>> >> >>> >> > below. >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > So, my proposal is supporting the message files with >>>>>>>>>>> UTF-8 >>>>>>>>>>> >> >>> >> > encoding. >>>>>>>>>>> >> >>> >> > I >>>>>>>>>>> >> >>> >> > believe that it's very developers/customers >>>>>>>>>>> friendly. In >>>>>>>>>>> >> >>> >> > addition, >>>>>>>>>>> >> >>> >> > we >>>>>>>>>>> >> >>> >> > can easily review the translated messages on the >>>>>>>>>>> github pull >>>>>>>>>>> >> >>> >> > request >>>>>>>>>>> >> >>> >> > view and so on. What do you think? >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a >>>>>>>>>>> pull request. >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > Regards, >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> >> >>> >> > -- >>>>>>>>>>> >> >>> >> > Hiroyuki Wada, >>>>>>>>>>> >> >>> >> > Developer, >>>>>>>>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>>>>>>>> >> >>> >> > _______________________________________________ >>>>>>>>>>> >> >>> >> > keycloak-dev mailing list >>>>>>>>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>>>>>>>> >> >>> >> > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> -- >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> abstractj >>>>>>>>>>> >> >>> >> PGP: 0x84DC9914 >>>>>>>>>>> >> >>> >> _______________________________________________ >>>>>>>>>>> >> >>> >> 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 >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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/20160715/37888ecb/attachment-0001.html From sthorger at redhat.com Fri Jul 15 04:41:56 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 15 Jul 2016 10:41:56 +0200 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: I tried iconv, but it doesn't do anything. Just outputs the iso-8859-1 as before: iconv -f iso-8859-1 -t utf-8 ./themes/src/main/resources/theme/base/login/messages/messages_ru.properties On 15 July 2016 at 09:04, Thomas Raehalme wrote: > iconv has been a good tool to convert files from one encoding to another. > > Best regards, > Thomas > > On Jul 15, 2016 09:57, "Hiroyuki Wada" wrote: > >> >> BTW do you have a reliable way to convert the files? I've tried various >>> tools, but none worked for me. >>> >> >> Yes, we can use native2ascii command. >> >> Example: >> native2ascii -encoding UTF-8 -reverse >> >> >> >> >>> On 15 July 2016 at 08:14, Stian Thorgersen wrote: >>> >>>> I'd like the current messages to be converted by the people that have >>>> contributed them. They will be able to determine what encoding they prefer >>>> to use and also confirm that the conversion has been successful. >>>> >>>> On 15 July 2016 at 07:59, Hiroyuki Wada wrote: >>>> >>>>> I mean I'd like to change the message files encoding only. >>>>> For example, admin-messages for Russian language is currently written >>>>> in ISO-8859-1 encoding. >>>>> >>>>> >>>>> https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/messages/admin-messages_ru.properties >>>>> >>>>> Can I convert the language messages except for English? >>>>> >>>>> >>>>> 2016?7?15?(?) 14:03 Stian Thorgersen : >>>>> >>>>>> No, we don't want the theme properties (and other properties files) >>>>>> to be utf-8. They should stick with the default encoding used by Java >>>>>> properties files. >>>>>> >>>>>> Messages are a special case, which is why we accepted it for them. >>>>>> >>>>>> On 14 July 2016 at 13:29, Hiroyuki Wada wrote: >>>>>> >>>>>>> Thank you for merging the pull request. Could I send a pull request >>>>>>> converting to UTF-8 encoding against the theme properties? >>>>>>> >>>>>>> 2016?7?7?(?) 21:39 Hiroyuki Wada : >>>>>>> >>>>>>>> Yes. I will send a pull request later! >>>>>>>> >>>>>>>> 2016?7?7?(?) 21:20 Stian Thorgersen : >>>>>>>> >>>>>>>>> Are you doing a PR as well? >>>>>>>>> >>>>>>>>> On 7 July 2016 at 12:33, Hiroyuki Wada wrote: >>>>>>>>> >>>>>>>>>> Ok. I created a JIRA issue. >>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>>>>>>>>> >>>>>>>>>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>>>>>>>>> >>>>>>>>>>> Let's go for it. Please create a JIRA and send PR. Please just >>>>>>>>>>> use "# encoding: utf-8" and not "# -*- coding: utf-8 -*-". The >>>>>>>>>>> latter is just weird if you ask me. >>>>>>>>>>> >>>>>>>>>>> Thomas: It's optional, defaults to iso-8859-1 and the header >>>>>>>>>>> will clearly state that a file uses a different encoding, so I disagree >>>>>>>>>>> that there will be any confusion. >>>>>>>>>>> >>>>>>>>>>> On 6 July 2016 at 12:30, Hiroyuki Wada >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>>>>>>>>> wrote: >>>>>>>>>>>> > From the javadoc of java.util.ResourceBundle the encoding for >>>>>>>>>>>> .properties is >>>>>>>>>>>> > still expected to be ISO-8859-1: >>>>>>>>>>>> > >>>>>>>>>>>> >> Constructing a PropertyResourceBundle instance from an >>>>>>>>>>>> InputStream >>>>>>>>>>>> >> requires that the input stream be encoded in ISO-8859-1. In >>>>>>>>>>>> that case, >>>>>>>>>>>> >> characters that cannot be represented in ISO-8859-1 encoding >>>>>>>>>>>> must be >>>>>>>>>>>> >> represented by Unicode Escapes as defined in section 3.3 of >>>>>>>>>>>> The Java? >>>>>>>>>>>> >> Language Specification whereas the other constructor which >>>>>>>>>>>> takes a Reader >>>>>>>>>>>> >> does not have that limitation. >>>>>>>>>>>> >>>>>>>>>>>> It's a case of using constructor which takes an InputStream. >>>>>>>>>>>> It says we can use any encoding when we use the other >>>>>>>>>>>> constructor >>>>>>>>>>>> which takes a Reader. >>>>>>>>>>>> >>>>>>>>>>>> I understand your concern. So what do you think supporting >>>>>>>>>>>> utf-8 with >>>>>>>>>>>> a header like Stian suggested? >>>>>>>>>>>> I think it can avoid confusion because the encoding is noted in >>>>>>>>>>>> the >>>>>>>>>>>> file itself... >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>>>>>>>>> > >>>>>>>>>>>> > I understand that Spring allows one to read .properties using >>>>>>>>>>>> any encoding, >>>>>>>>>>>> > but you need to specify the encoding in Spring configuration >>>>>>>>>>>> external to the >>>>>>>>>>>> > .properties file. >>>>>>>>>>>> > >>>>>>>>>>>> > In my opinion it would cause unnecessary confusion amongst >>>>>>>>>>>> developers to use >>>>>>>>>>>> > any other encoding than the one defined by the official >>>>>>>>>>>> documentation for >>>>>>>>>>>> > Properties. >>>>>>>>>>>> > >>>>>>>>>>>> > Best regards, >>>>>>>>>>>> > Thomas >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada < >>>>>>>>>>>> wadahiro at gmail.com> wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> I think it was true before Java 1.6 because Java standard >>>>>>>>>>>> library >>>>>>>>>>>> >> (java.util.ResourceBundle or java.util.Properties) only >>>>>>>>>>>> supported >>>>>>>>>>>> >> ISO-8859-1 encoding file. >>>>>>>>>>>> >> But they support any encoding after Java 1.6. There are some >>>>>>>>>>>> >> frameworks which can read .properties with any encoding. For >>>>>>>>>>>> example, >>>>>>>>>>>> >> Spring Framework can read .properties with any encoding. I >>>>>>>>>>>> think it's >>>>>>>>>>>> >> very useful to read UTF-8 directly for multibyte language >>>>>>>>>>>> country. >>>>>>>>>>>> >> >>>>>>>>>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>>>>>>>>> >> wrote: >>>>>>>>>>>> >> > Please correct me if I am wrong, but I have been under the >>>>>>>>>>>> impression >>>>>>>>>>>> >> > that >>>>>>>>>>>> >> > Java .properties files should always use encoding >>>>>>>>>>>> ISO-8859-1. Characters >>>>>>>>>>>> >> > not >>>>>>>>>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it >>>>>>>>>>>> make things >>>>>>>>>>>> >> > confusing to developers if another encoding is used here >>>>>>>>>>>> instead? >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > If alternate encodings are desired how about supporting >>>>>>>>>>>> the XML format >>>>>>>>>>>> >> > of >>>>>>>>>>>> >> > Properties? >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > Best regards, >>>>>>>>>>>> >> > Thomas >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>>>>>>>>> sthorger at redhat.com> >>>>>>>>>>>> >> > wrote: >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able >>>>>>>>>>>> to co-exist. >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> We can allow specifying the encoding in a comment on the >>>>>>>>>>>> first line >>>>>>>>>>>> >> >> like >>>>>>>>>>>> >> >> this: >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> # encoding=utf-8 >>>>>>>>>>>> >> >> key=value >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> # encoding=iso-8859-1 >>>>>>>>>>>> >> >> key=value >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> If the first line in the file doesn't contain the comment >>>>>>>>>>>> with the >>>>>>>>>>>> >> >> encoding then we should default to iso-8859-1 for >>>>>>>>>>>> backwards >>>>>>>>>>>> >> >> compatibility >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada < >>>>>>>>>>>> wadahiro at gmail.com> wrote: >>>>>>>>>>>> >> >>> >>>>>>>>>>>> >> >>> Thanks for your comment. >>>>>>>>>>>> >> >>> >>>>>>>>>>>> >> >>> > If we want to change to utf-8 we'd still need to >>>>>>>>>>>> support iso.. for >>>>>>>>>>>> >> >>> > backwards compatibility. >>>>>>>>>>>> >> >>> >>>>>>>>>>>> >> >>> If we change to UTF-8, we can still read unicode >>>>>>>>>>>> codepoint like >>>>>>>>>>>> >> >>> '\u00e8'. >>>>>>>>>>>> >> >>> There is an incompatibility when non-ascii characters >>>>>>>>>>>> are used in >>>>>>>>>>>> >> >>> message properties. >>>>>>>>>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please >>>>>>>>>>>> refer codepage >>>>>>>>>>>> >> >>> layout: >>>>>>>>>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>>>>>>>>> >> >>> >>>>>>>>>>>> >> >>> I think the non-ascii characters might be used in French >>>>>>>>>>>> messages like >>>>>>>>>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>>>>>>>>> compatibility. >>>>>>>>>>>> >> >>> To support this, I think we can add a property like >>>>>>>>>>>> "messageEncoding" >>>>>>>>>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>>>>>>>>> >> >>> >>>>>>>>>>>> >> >>> "theme": { >>>>>>>>>>>> >> >>> "staticMaxAge": 2592000, >>>>>>>>>>>> >> >>> "cacheTemplates": true, >>>>>>>>>>>> >> >>> "cacheThemes": true, >>>>>>>>>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>>>>>>>>> >> >>> "folder": { >>>>>>>>>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>>>>>>>>> >> >>> } >>>>>>>>>>>> >> >>> }, >>>>>>>>>>>> >> >>> >>>>>>>>>>>> >> >>> Regards, >>>>>>>>>>>> >> >>> >>>>>>>>>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>>>>>>>>> >> >>> >>>>>>>>>>>> >> >>> wrote: >>>>>>>>>>>> >> >>> > We have in the past discussed this and decided to >>>>>>>>>>>> stick with >>>>>>>>>>>> >> >>> > ISO-8859-1. >>>>>>>>>>>> >> >>> > That was probably not the best idea though. If we want >>>>>>>>>>>> to change to >>>>>>>>>>>> >> >>> > utf-8 >>>>>>>>>>>> >> >>> > we'd still need to support iso.. for backwards >>>>>>>>>>>> compatibility. >>>>>>>>>>>> >> >>> > >>>>>>>>>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira < >>>>>>>>>>>> bruno at abstractj.org> wrote: >>>>>>>>>>>> >> >>> >> >>>>>>>>>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>>>>>>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>>>>>>>> >> >>> >> >>>>>>>>>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>>>>>>>> >> >>> >> > Hello all, >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > I am trying to translate all base theme messages to >>>>>>>>>>>> my country >>>>>>>>>>>> >> >>> >> > language, Japanese. And I'd like to contribute >>>>>>>>>>>> them. Before that >>>>>>>>>>>> >> >>> >> > work, >>>>>>>>>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > Currently, the message files (*.properties) are >>>>>>>>>>>> loaded with >>>>>>>>>>>> >> >>> >> > ISO-8859-1 >>>>>>>>>>>> >> >>> >> > encoding. Therefore, it is necessary to convert the >>>>>>>>>>>> files by >>>>>>>>>>>> >> >>> >> > 'native2ascii' command beforehand. However we can >>>>>>>>>>>> directly read >>>>>>>>>>>> >> >>> >> > the >>>>>>>>>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or >>>>>>>>>>>> later because >>>>>>>>>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method >>>>>>>>>>>> was introduced >>>>>>>>>>>> >> >>> >> > as >>>>>>>>>>>> >> >>> >> > below. >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > So, my proposal is supporting the message files >>>>>>>>>>>> with UTF-8 >>>>>>>>>>>> >> >>> >> > encoding. >>>>>>>>>>>> >> >>> >> > I >>>>>>>>>>>> >> >>> >> > believe that it's very developers/customers >>>>>>>>>>>> friendly. In >>>>>>>>>>>> >> >>> >> > addition, >>>>>>>>>>>> >> >>> >> > we >>>>>>>>>>>> >> >>> >> > can easily review the translated messages on the >>>>>>>>>>>> github pull >>>>>>>>>>>> >> >>> >> > request >>>>>>>>>>>> >> >>> >> > view and so on. What do you think? >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a >>>>>>>>>>>> pull request. >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > Regards, >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> >> >>> >> > -- >>>>>>>>>>>> >> >>> >> > Hiroyuki Wada, >>>>>>>>>>>> >> >>> >> > Developer, >>>>>>>>>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>>>>>>>>> >> >>> >> > _______________________________________________ >>>>>>>>>>>> >> >>> >> > keycloak-dev mailing list >>>>>>>>>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>> >> >>> >> >>>>>>>>>>>> >> >>> >> -- >>>>>>>>>>>> >> >>> >> >>>>>>>>>>>> >> >>> >> abstractj >>>>>>>>>>>> >> >>> >> PGP: 0x84DC9914 >>>>>>>>>>>> >> >>> >> _______________________________________________ >>>>>>>>>>>> >> >>> >> 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 >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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/20160715/de7fe675/attachment-0001.html From wadahiro at gmail.com Fri Jul 15 05:10:34 2016 From: wadahiro at gmail.com (Hiroyuki Wada) Date: Fri, 15 Jul 2016 09:10:34 +0000 Subject: [keycloak-dev] Support UTF-8 encoding theme message properites In-Reply-To: References: <20160704123711.GA6017@abstractj.org> Message-ID: I tried native2ascii. It looks good. native2ascii -encoding UTF-8 -reverse messages_ru.properties messages_ru.properties == Before invalidPasswordMinLengthMessage=\u041D\u0435\u043A\u043E\u0440\u0440\u0435\u043A\u0442\u043D\u044B\u0439 \u043F\u0430\u0440\u043E\u043B\u044C: \u043C\u0438\u043D\u0438\u043C\u0430\u043B\u044C\u043D\u0430\u044F \u0434\u043B\u0438\u043D\u0430 {0}. == After invalidPasswordMinLengthMessage=???????????? ??????: ??????????? ????? {0}. 2016?7?15?(?) 17:41 Stian Thorgersen : > I tried iconv, but it doesn't do anything. Just outputs the iso-8859-1 as > before: > > iconv -f iso-8859-1 -t utf-8 > ./themes/src/main/resources/theme/base/login/messages/messages_ru.properties > > On 15 July 2016 at 09:04, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> iconv has been a good tool to convert files from one encoding to another. >> >> Best regards, >> Thomas >> >> On Jul 15, 2016 09:57, "Hiroyuki Wada" wrote: >> >>> >>> BTW do you have a reliable way to convert the files? I've tried various >>>> tools, but none worked for me. >>>> >>> >>> Yes, we can use native2ascii command. >>> >>> Example: >>> native2ascii -encoding UTF-8 -reverse >>> >>> >>> >>> >>>> On 15 July 2016 at 08:14, Stian Thorgersen wrote: >>>> >>>>> I'd like the current messages to be converted by the people that have >>>>> contributed them. They will be able to determine what encoding they prefer >>>>> to use and also confirm that the conversion has been successful. >>>>> >>>>> On 15 July 2016 at 07:59, Hiroyuki Wada wrote: >>>>> >>>>>> I mean I'd like to change the message files encoding only. >>>>>> For example, admin-messages for Russian language is currently written >>>>>> in ISO-8859-1 encoding. >>>>>> >>>>>> >>>>>> https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/messages/admin-messages_ru.properties >>>>>> >>>>>> Can I convert the language messages except for English? >>>>>> >>>>>> >>>>>> 2016?7?15?(?) 14:03 Stian Thorgersen : >>>>>> >>>>>>> No, we don't want the theme properties (and other properties files) >>>>>>> to be utf-8. They should stick with the default encoding used by Java >>>>>>> properties files. >>>>>>> >>>>>>> Messages are a special case, which is why we accepted it for them. >>>>>>> >>>>>>> On 14 July 2016 at 13:29, Hiroyuki Wada wrote: >>>>>>> >>>>>>>> Thank you for merging the pull request. Could I send a pull request >>>>>>>> converting to UTF-8 encoding against the theme properties? >>>>>>>> >>>>>>>> 2016?7?7?(?) 21:39 Hiroyuki Wada : >>>>>>>> >>>>>>>>> Yes. I will send a pull request later! >>>>>>>>> >>>>>>>>> 2016?7?7?(?) 21:20 Stian Thorgersen : >>>>>>>>> >>>>>>>>>> Are you doing a PR as well? >>>>>>>>>> >>>>>>>>>> On 7 July 2016 at 12:33, Hiroyuki Wada >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Ok. I created a JIRA issue. >>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3278 >>>>>>>>>>> >>>>>>>>>>> 2016?7?6?(?) 19:36 Stian Thorgersen : >>>>>>>>>>> >>>>>>>>>>>> Let's go for it. Please create a JIRA and send PR. Please just >>>>>>>>>>>> use "# encoding: utf-8" and not "# -*- coding: utf-8 -*-". The >>>>>>>>>>>> latter is just weird if you ask me. >>>>>>>>>>>> >>>>>>>>>>>> Thomas: It's optional, defaults to iso-8859-1 and the header >>>>>>>>>>>> will clearly state that a file uses a different encoding, so I disagree >>>>>>>>>>>> that there will be any confusion. >>>>>>>>>>>> >>>>>>>>>>>> On 6 July 2016 at 12:30, Hiroyuki Wada >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 6, 2016 at 6:53 PM, Thomas Raehalme >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> > From the javadoc of java.util.ResourceBundle the encoding >>>>>>>>>>>>> for .properties is >>>>>>>>>>>>> > still expected to be ISO-8859-1: >>>>>>>>>>>>> > >>>>>>>>>>>>> >> Constructing a PropertyResourceBundle instance from an >>>>>>>>>>>>> InputStream >>>>>>>>>>>>> >> requires that the input stream be encoded in ISO-8859-1. In >>>>>>>>>>>>> that case, >>>>>>>>>>>>> >> characters that cannot be represented in ISO-8859-1 >>>>>>>>>>>>> encoding must be >>>>>>>>>>>>> >> represented by Unicode Escapes as defined in section 3.3 of >>>>>>>>>>>>> The Java? >>>>>>>>>>>>> >> Language Specification whereas the other constructor which >>>>>>>>>>>>> takes a Reader >>>>>>>>>>>>> >> does not have that limitation. >>>>>>>>>>>>> >>>>>>>>>>>>> It's a case of using constructor which takes an InputStream. >>>>>>>>>>>>> It says we can use any encoding when we use the other >>>>>>>>>>>>> constructor >>>>>>>>>>>>> which takes a Reader. >>>>>>>>>>>>> >>>>>>>>>>>>> I understand your concern. So what do you think supporting >>>>>>>>>>>>> utf-8 with >>>>>>>>>>>>> a header like Stian suggested? >>>>>>>>>>>>> I think it can avoid confusion because the encoding is noted >>>>>>>>>>>>> in the >>>>>>>>>>>>> file itself... >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/PropertyResourceBundle.html >>>>>>>>>>>>> > >>>>>>>>>>>>> > I understand that Spring allows one to read .properties >>>>>>>>>>>>> using any encoding, >>>>>>>>>>>>> > but you need to specify the encoding in Spring configuration >>>>>>>>>>>>> external to the >>>>>>>>>>>>> > .properties file. >>>>>>>>>>>>> > >>>>>>>>>>>>> > In my opinion it would cause unnecessary confusion amongst >>>>>>>>>>>>> developers to use >>>>>>>>>>>>> > any other encoding than the one defined by the official >>>>>>>>>>>>> documentation for >>>>>>>>>>>>> > Properties. >>>>>>>>>>>>> > >>>>>>>>>>>>> > Best regards, >>>>>>>>>>>>> > Thomas >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > On Wed, Jul 6, 2016 at 12:40 PM, Hiroyuki Wada < >>>>>>>>>>>>> wadahiro at gmail.com> wrote: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> I think it was true before Java 1.6 because Java standard >>>>>>>>>>>>> library >>>>>>>>>>>>> >> (java.util.ResourceBundle or java.util.Properties) only >>>>>>>>>>>>> supported >>>>>>>>>>>>> >> ISO-8859-1 encoding file. >>>>>>>>>>>>> >> But they support any encoding after Java 1.6. There are some >>>>>>>>>>>>> >> frameworks which can read .properties with any encoding. >>>>>>>>>>>>> For example, >>>>>>>>>>>>> >> Spring Framework can read .properties with any encoding. I >>>>>>>>>>>>> think it's >>>>>>>>>>>>> >> very useful to read UTF-8 directly for multibyte language >>>>>>>>>>>>> country. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> On Wed, Jul 6, 2016 at 3:32 PM, Thomas Raehalme >>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> >> > Please correct me if I am wrong, but I have been under >>>>>>>>>>>>> the impression >>>>>>>>>>>>> >> > that >>>>>>>>>>>>> >> > Java .properties files should always use encoding >>>>>>>>>>>>> ISO-8859-1. Characters >>>>>>>>>>>>> >> > not >>>>>>>>>>>>> >> > present in ISO-8859-1 can be written in \uxxxx. Won't it >>>>>>>>>>>>> make things >>>>>>>>>>>>> >> > confusing to developers if another encoding is used here >>>>>>>>>>>>> instead? >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.InputStream- >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#store-java.io.OutputStream-java.lang.String- >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > If alternate encodings are desired how about supporting >>>>>>>>>>>>> the XML format >>>>>>>>>>>>> >> > of >>>>>>>>>>>>> >> > Properties? >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > Best regards, >>>>>>>>>>>>> >> > Thomas >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > On Wed, Jul 6, 2016 at 9:04 AM, Stian Thorgersen < >>>>>>>>>>>>> sthorger at redhat.com> >>>>>>>>>>>>> >> > wrote: >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> Both iso-8859-1 and utf-8 message bundles should be able >>>>>>>>>>>>> to co-exist. >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> We can allow specifying the encoding in a comment on the >>>>>>>>>>>>> first line >>>>>>>>>>>>> >> >> like >>>>>>>>>>>>> >> >> this: >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> # encoding=utf-8 >>>>>>>>>>>>> >> >> key=value >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> # encoding=iso-8859-1 >>>>>>>>>>>>> >> >> key=value >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> If the first line in the file doesn't contain the >>>>>>>>>>>>> comment with the >>>>>>>>>>>>> >> >> encoding then we should default to iso-8859-1 for >>>>>>>>>>>>> backwards >>>>>>>>>>>>> >> >> compatibility >>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> On 5 July 2016 at 09:49, Hiroyuki Wada < >>>>>>>>>>>>> wadahiro at gmail.com> wrote: >>>>>>>>>>>>> >> >>> >>>>>>>>>>>>> >> >>> Thanks for your comment. >>>>>>>>>>>>> >> >>> >>>>>>>>>>>>> >> >>> > If we want to change to utf-8 we'd still need to >>>>>>>>>>>>> support iso.. for >>>>>>>>>>>>> >> >>> > backwards compatibility. >>>>>>>>>>>>> >> >>> >>>>>>>>>>>>> >> >>> If we change to UTF-8, we can still read unicode >>>>>>>>>>>>> codepoint like >>>>>>>>>>>>> >> >>> '\u00e8'. >>>>>>>>>>>>> >> >>> There is an incompatibility when non-ascii characters >>>>>>>>>>>>> are used in >>>>>>>>>>>>> >> >>> message properties. >>>>>>>>>>>>> >> >>> The non-ascii characters are 0xA0 - 0xFF codes (please >>>>>>>>>>>>> refer codepage >>>>>>>>>>>>> >> >>> layout: >>>>>>>>>>>>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout ) >>>>>>>>>>>>> >> >>> >>>>>>>>>>>>> >> >>> I think the non-ascii characters might be used in >>>>>>>>>>>>> French messages like >>>>>>>>>>>>> >> >>> '?' so I agree to support ISO-8859-1 for backwards >>>>>>>>>>>>> compatibility. >>>>>>>>>>>>> >> >>> To support this, I think we can add a property like >>>>>>>>>>>>> "messageEncoding" >>>>>>>>>>>>> >> >>> in keycloak-server.json as below. Is it a good idea? >>>>>>>>>>>>> >> >>> >>>>>>>>>>>>> >> >>> "theme": { >>>>>>>>>>>>> >> >>> "staticMaxAge": 2592000, >>>>>>>>>>>>> >> >>> "cacheTemplates": true, >>>>>>>>>>>>> >> >>> "cacheThemes": true, >>>>>>>>>>>>> >> >>> "messageEncoding": "ISO-8859-1", >>>>>>>>>>>>> >> >>> "folder": { >>>>>>>>>>>>> >> >>> "dir": "${jboss.home.dir}/themes" >>>>>>>>>>>>> >> >>> } >>>>>>>>>>>>> >> >>> }, >>>>>>>>>>>>> >> >>> >>>>>>>>>>>>> >> >>> Regards, >>>>>>>>>>>>> >> >>> >>>>>>>>>>>>> >> >>> On Mon, Jul 4, 2016 at 10:33 PM, Stian Thorgersen >>>>>>>>>>>>> >> >>> >>>>>>>>>>>>> >> >>> wrote: >>>>>>>>>>>>> >> >>> > We have in the past discussed this and decided to >>>>>>>>>>>>> stick with >>>>>>>>>>>>> >> >>> > ISO-8859-1. >>>>>>>>>>>>> >> >>> > That was probably not the best idea though. If we >>>>>>>>>>>>> want to change to >>>>>>>>>>>>> >> >>> > utf-8 >>>>>>>>>>>>> >> >>> > we'd still need to support iso.. for backwards >>>>>>>>>>>>> compatibility. >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > On 4 July 2016 at 14:37, Bruno Oliveira < >>>>>>>>>>>>> bruno at abstractj.org> wrote: >>>>>>>>>>>>> >> >>> >> >>>>>>>>>>>>> >> >>> >> It makes sense, maybe file a Jira associated with: >>>>>>>>>>>>> >> >>> >> https://issues.jboss.org/browse/KEYCLOAK-3259 ? >>>>>>>>>>>>> >> >>> >> >>>>>>>>>>>>> >> >>> >> On 2016-07-04, Hiroyuki Wada wrote: >>>>>>>>>>>>> >> >>> >> > Hello all, >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > I am trying to translate all base theme messages >>>>>>>>>>>>> to my country >>>>>>>>>>>>> >> >>> >> > language, Japanese. And I'd like to contribute >>>>>>>>>>>>> them. Before that >>>>>>>>>>>>> >> >>> >> > work, >>>>>>>>>>>>> >> >>> >> > I'd like to propose about the files encoding. >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > Currently, the message files (*.properties) are >>>>>>>>>>>>> loaded with >>>>>>>>>>>>> >> >>> >> > ISO-8859-1 >>>>>>>>>>>>> >> >>> >> > encoding. Therefore, it is necessary to convert >>>>>>>>>>>>> the files by >>>>>>>>>>>>> >> >>> >> > 'native2ascii' command beforehand. However we can >>>>>>>>>>>>> directly read >>>>>>>>>>>>> >> >>> >> > the >>>>>>>>>>>>> >> >>> >> > property files with UTF-8 encoding in java 1.6 or >>>>>>>>>>>>> later because >>>>>>>>>>>>> >> >>> >> > 'java.util.Properties#load(java.io.Reader)' method >>>>>>>>>>>>> was introduced >>>>>>>>>>>>> >> >>> >> > as >>>>>>>>>>>>> >> >>> >> > below. >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html#load(java.io.Reader) >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > So, my proposal is supporting the message files >>>>>>>>>>>>> with UTF-8 >>>>>>>>>>>>> >> >>> >> > encoding. >>>>>>>>>>>>> >> >>> >> > I >>>>>>>>>>>>> >> >>> >> > believe that it's very developers/customers >>>>>>>>>>>>> friendly. In >>>>>>>>>>>>> >> >>> >> > addition, >>>>>>>>>>>>> >> >>> >> > we >>>>>>>>>>>>> >> >>> >> > can easily review the translated messages on the >>>>>>>>>>>>> github pull >>>>>>>>>>>>> >> >>> >> > request >>>>>>>>>>>>> >> >>> >> > view and so on. What do you think? >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > If it's ok, I'll create a JIRA issue and create a >>>>>>>>>>>>> pull request. >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > Regards, >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> >> >>> >> > -- >>>>>>>>>>>>> >> >>> >> > Hiroyuki Wada, >>>>>>>>>>>>> >> >>> >> > Developer, >>>>>>>>>>>>> >> >>> >> > Nomura Research Institute, Ltd. >>>>>>>>>>>>> >> >>> >> > _______________________________________________ >>>>>>>>>>>>> >> >>> >> > keycloak-dev mailing list >>>>>>>>>>>>> >> >>> >> > keycloak-dev at lists.jboss.org >>>>>>>>>>>>> >> >>> >> > >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>>>> >> >>> >> >>>>>>>>>>>>> >> >>> >> -- >>>>>>>>>>>>> >> >>> >> >>>>>>>>>>>>> >> >>> >> abstractj >>>>>>>>>>>>> >> >>> >> PGP: 0x84DC9914 >>>>>>>>>>>>> >> >>> >> _______________________________________________ >>>>>>>>>>>>> >> >>> >> 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 >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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/20160715/a7c43755/attachment-0001.html From mitya at cargosoft.ru Fri Jul 15 14:28:57 2016 From: mitya at cargosoft.ru (Mitya) Date: Fri, 15 Jul 2016 21:28:57 +0300 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: References: <1468323778.4229.4.camel@cargosoft.ru> Message-ID: <1468607337.4292.5.camel@cargosoft.ru> Stian, In my provider, session.getContext().getRealm() returns an instance of?org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. What's the best way to obtain it? I've yet come up with the following: RealmModel realm = session.getContext().getRealm(); RealmAdapter adapter = (RealmAdapter) session.getProvider(RealmProvider.class).getRealm(realm.getId()); > Realm attributes should be perfect for that > > > On 12 July 2016 at 13:42, Mitya wrote: > > Hi, > > > > > > > > I'm developing a KeyCloak extension, and I want some custom (per- realm) parameters to be tuned via the GUI form. Speaking of the storage mechanism for my settings, are realm attributes suitable for that? or should I create a dedicated custom entity instead? > > > > Thx, > > Mitya > > > > > > _______________________________________________ > > > > 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/20160715/d856a13c/attachment.html From michael_furman at hotmail.com Sun Jul 17 11:12:13 2016 From: michael_furman at hotmail.com (Michael Furman) Date: Sun, 17 Jul 2016 15:12:13 +0000 Subject: [keycloak-dev] Reuse of OpenID Connect IDP Message-ID: Dear Keycloak people, I need your help. Where is in code located the OpenID Connect IDP? Is it possible to reuse of the OpenID Connect IDP with other authentication framework? Thanks in advance, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160717/a0457aac/attachment.html From sthorger at redhat.com Mon Jul 18 01:39:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 18 Jul 2016 07:39:04 +0200 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: <1468607337.4292.5.camel@cargosoft.ru> References: <1468323778.4229.4.camel@cargosoft.ru> <1468607337.4292.5.camel@cargosoft.ru> Message-ID: Forgot that attributes are not exposed through RealmModel. You can't access the JPA RealmAdapter directly as you'll break the cache functionality. You can create a JIRA to request attributes added to RealmModel though. On 15 July 2016 at 20:28, Mitya wrote: > Stian, > > In my provider, session.getContext().getRealm() returns an instance > of org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be > able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. > What's the best way to obtain it? > > I've yet come up with the following: > > RealmModel realm = session.getContext().getRealm(); > RealmAdapter adapter = (RealmAdapter) > session.getProvider(RealmProvider.class).getRealm(realm.getId()); > > > Realm attributes should be perfect for that > > On 12 July 2016 at 13:42, Mitya wrote: > > Hi, > > I'm developing a KeyCloak extension, and I want some custom (per-realm) > parameters to be tuned via the GUI form. Speaking of the storage mechanism > for my settings, are realm attributes suitable for that? or should I create > a dedicated custom entity instead? > > Thx, > Mitya > > _______________________________________________ > 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/20160718/74fce032/attachment.html From e.berdoncesbonelo at campus.tu-berlin.de Mon Jul 18 12:19:53 2016 From: e.berdoncesbonelo at campus.tu-berlin.de (Erik Berdonces Bonelo) Date: Mon, 18 Jul 2016 18:19:53 +0200 Subject: [keycloak-dev] Debugging with an IDE configuration Message-ID: Hello, I?m trying to implement a custom made REST endpoint in Keycloak following the documentation in?https://keycloak.gitbooks.io/server-developer-guide/content/v/2.0/topics/extensions.html As I see I have to compile the module and deploy it to Keycloak. So, is there any easy way to deploy/debug into a Keycloak instance? As I see, the documentation in the Github repo recommends to use standalone.sh to start the server and I can add the debug flag. But, that doesn?t exist in the repository. Any guidance in this? Also, any maven commands to fast deploy the module into the Keycloak instance? At the moment I?ve only found that I should run Keycloak in debug mode and then attach to port 8787, but well, first I need to find how to run it from the source... I could even help to extend the documentation with some steps in order to setup an easy dev setup, so people can contribute easier in exchange of the help :) Thanks a lot! ?? Best Regards,? Erik Berdonces Bonelo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160718/f2edb9b1/attachment.html From josh.cain at redhat.com Mon Jul 18 13:19:12 2016 From: josh.cain at redhat.com (Josh Cain) Date: Mon, 18 Jul 2016 12:19:12 -0500 Subject: [keycloak-dev] Authorization Code Flow as Default for Javascript? In-Reply-To: References: Message-ID: Thanks for the quick response Stian! Still getting my feet wet with OIDC, so please bear with me as I try to reconcile what I'm reading @ the spec with the Keycloak implementation. A few questions on your response: You say that it's 'usual' for these access tokens to have a long lifespan with implicit flow. How does that interact with the general guideline in section 16.18 of the spec when it says: Access Tokens might not be revocable by the Authorization Server. Access > Token lifetimes SHOULD therefore be kept to single use or very short > lifetimes. I would agree that a long-lived refresh token is indeed much preferred to doing something like extending the lifetime of an access token. However, is 'the OAuth redirect dance' the only alternative? I know that Keycloak's identity/session cookies will have been issued at this point - would it be possible to use something like an iFrame to refresh a short-lived access token? Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 On Wed, Jul 13, 2016 at 1:37 AM, Stian Thorgersen wrote: > With Implicit flow it's usual to have a long expiration on access tokens > as there is no refresh token. Once the access token is expired you're left > with having to do the whole OAuth redirect dance again to obtain a new > token. What's even worse is that if you have long lived access tokens > there's potentially a longer time between the verification of > the access token directly with Keycloak, which means that an access token > could potentially be used long after the session has been removed. > > With that in mind having short lived access tokens with a refresh token is > better in our opinion even for public clients. > > On 12 July 2016 at 19:22, Josh Cain wrote: > >> Hi All, >> >> We're looking to start rolling the Keycloak OIDC flow out to some >> client-side Javascript applications, and I came across a question in coming >> up to speed on OIDC. You state in your docs >> >> that the Javascript adapter is intended for client-side use: >> >> Keycloak comes with a client-side JavaScript library that can be used to >>> secure HTML5/JavaScript applications. >>> >> >> The docs also state that the default flow for this adapter is the >> Authorization Code flow: >> >> By default, the JavaScript adapter uses the Authorization Code >>> >>> flow. >>> >> >> However, the OIDC spec >> says (section >> 3.1): >> >> ...The Authorization Code flow is suitable for Clients that can securely >>> maintain a Client Secret between themselves and the Authorization Server. >>> >> >> And again echoes the sentiment using the non-requisite MAY language in >> section 15.4: >> >> In general, it is up to Relying Parties which features they use when >>> interacting with OpenID Providers. However, some choices are dictated by >>> the nature of their OAuth Client, such as whether it is a Confidential >>> Client, capable of keeping secrets, in which case the Authorization Code >>> Flow may be appropriate, or whether it is a Public Client, for instance, a >>> User Agent Based Application or a statically registered Native Application, >>> in which case the Implicit Flow may be appropriate. >>> >> >> I'm aware that public clients who do not present a client secret are >> allowed under the OAuth spec , and >> that these are often the type of javascript client that Keycloak sets up >> with the authorization code flow. What's more, I understand that the >> client secret is most commonly the reason cited for the client/server >> distinction with respect to flows. >> >> However, I was curious as to why the authorization code flow remains the >> default setting for Javascript applications. Isn't the refresh token also >> considered a form of a 'secret' since it's a long-lived mechanism whereby >> additional access/identity tokens can be retrieved? Why would the default >> setting *not* be implicit here? Could you help me understand why the >> authorization code flow was chosen as the default? >> >> Thanks in advance! >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 843-737-1735 >> >> _______________________________________________ >> 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/20160718/603a119d/attachment-0001.html From mitya at cargosoft.ru Mon Jul 18 13:55:01 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Mon, 18 Jul 2016 20:55:01 +0300 Subject: [keycloak-dev] Debugging with an IDE configuration In-Reply-To: References: Message-ID: <1468864501.5715.19.camel@cargosoft.ru> Hi, I've recently had an experience of developing/deploying/debugging a KeyCloak extension, which includes, among other things, a custom REST endpoint. For me, the following workflow did the thing. It is assumed that you've downloaded and unpacked a binary KeyCloak distro: 1) clone a KeyCloak Git repository. There is no need to build KeyCloak, since modules can be pretty easily deployed to an existing instance. You will need sources for debugging only. Use the branch/tag that corresponds to the binary version you've downloaded; 2) open KeyCloak source as a Maven project(s) in your IDE (I use NetBeans); 3) build and deploy your module. Until last week, I used to copy module JAR to the target directory upon each build, but then I've stumbled upon the recent KeyCloak blog?post. It's very convenient, especially for development/testing environments, to have extension modules deployed right from the Maven repo; 4) start KeyCloak with bin/standalone.sh --debug 5) attach your IDE's debugger to localhost:8787 using dt_socket transport (it could be also called "SocketAttach connector"); 6) set up some breakpoints, invoke your REST service to hit a breakpoint, and voil?! As for documenting development process, I completely share your point. Ideally, we should have a detailed walkthrough tutorial for writing complete KeyCloak extensions. At the moment all we've got is a chapter in the docs and some scattered examples in the repo. At the same time, what I've been developing recently is a full- featured, complete extension that includes: - custom JPA entity; - custom REST resource; - custom authenticator; - custom GUI to manage this all; - code that sets up custom roles and authentication workflows. I think I could convert my experience into such a tutorial. I'll elaborate on this in one of my next postings to this ML; I could put you on CC if you wish, so that you don't miss it. Cheers, Dmitry > Hello, > > > > I?m trying to implement a custom made REST endpoint in Keycloak following the documentation in?https://keycloak.gitbooks.io/server-de veloper-guide/content/v/2.0/topics/extensions.html > > As I see I have to compile the module and deploy it to Keycloak. So, is there any easy way to deploy/debug into a Keycloak instance? > > > > As I see, the documentation in the Github repo recommends to use standalone.sh to start the server and I can add the debug flag. But, that doesn?t exist in the repository. Any guidance in this? > > Also, any maven commands to fast deploy the module into the Keycloak instance? > > > > At the moment I?ve only found that I should run Keycloak in debug mode and then attach to port 8787, but well, first I need to find how to run it from the source... > > > > I could even help to extend the documentation with some steps in order to setup an easy dev setup, so people can contribute easier in exchange of the help :) > > Thanks a lot! > ?? > > > ?? > Best Regards,? > > Erik Berdonces Bonelo > > _______________________________________________ > 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/20160718/bc78824b/attachment.html From mitya at cargosoft.ru Mon Jul 18 16:35:46 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Mon, 18 Jul 2016 23:35:46 +0300 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: References: <1468323778.4229.4.camel@cargosoft.ru> <1468607337.4292.5.camel@cargosoft.ru> Message-ID: <1468874146.6797.11.camel@cargosoft.ru> Stian, Here we go:?https://issues.jboss.org/browse/KEYCLOAK-3327 If the fix is somewhat trivial (i.e. a matter of adding fields and getters/setters) I think I could work on a PR as well. BTW, does this mean that all the custom entities provided via Entity SPI are not by default cache-enabled (and won't be synchronized between the nodes in clustered environment)? If so, will it be easy to cache-enable them? Is this just a matter of providing Infinispan adapters similar to existing ones for Realm/User/Role/Client etc.? Ideally, I'd like to see a current domain-extension example augmented with Infinispan cache functionality. I've got some ideas on a detailed walkthrough tutorial for building complete, full-featured KeyCloak extensions (it's a big topic I'll elaborate on a bit later); I think Infinispan-enabled entities could be covered there, too. Regards, Dmitry ? ??, 18/07/2016 ? 07:39 +0200, Stian Thorgersen ?????: > > > > Forgot that attributes are not exposed through RealmModel. You can't access the JPA RealmAdapter directly as you'll break the cache functionality. You can create a JIRA to request attributes added to RealmModel though. > > > On 15 July 2016 at 20:28, Mitya wrote: > > Stian, > > > > > > > > > > In my provider, session.getContext().getRealm() returns an instance of?org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. What's the best way to obtain it? > > > > I've yet come up with the following: > > > > RealmModel realm = session.getContext().getRealm(); > > > > RealmAdapter adapter = (RealmAdapter) session.getProvider(RealmProvider.class).getRealm(realm.getId()); > > > > > > > Realm attributes should be perfect for that > > > > > > On 12 July 2016 at 13:42, Mitya wrote: > > > > Hi, > > > > > > > > > > > > > > > > > > > > I'm developing a KeyCloak extension, and I want some custom (per-realm) parameters to be tuned via the GUI form. Speaking of the storage mechanism for my settings, are realm attributes suitable for that? or should I create a dedicated custom entity instead? > > > > > > > > Thx, > > > > Mitya > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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/20160718/0b80a7a6/attachment.html From bruno at abstractj.org Mon Jul 18 18:48:30 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 18 Jul 2016 19:48:30 -0300 Subject: [keycloak-dev] PAM Conversations - Custom login form Message-ID: <20160718224830.GA4459@abstractj.org> Good morning, Today to authentication against PAM with just simple username/password I implemented UserFederationProvider and added the proper PAM login to validCredentials[1]. This covers the most basic scenario. Now I would like to cover a more complex scenario like OTP and change the flow a little bit like this: 1. User providers her username 2. The next screen asks to provide how many factor our user has(For example: OTP, password). We just don't know, PAM will tell what's next. 3. We authenticate against it To see in practice against FreeIPA server, I just recorded it for a practical example[2]. What would be the best approach to implement this flow? I was considering to move my authentication logic out of SSSD federation provider and create a PAM authenticator. Does it make sense? [1] - http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a -- abstractj PGP: 0x84DC9914 From singhrasster at gmail.com Mon Jul 18 20:19:14 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Mon, 18 Jul 2016 19:19:14 -0500 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true Message-ID: In my AuthenticatorFactory class, I have the following configuration added: ProviderConfigProperty property; property= new ProviderConfigProperty(); property.setName("propname"); property.setLabel("Property Name"); property.setDefaultValue(true); property.setType(ProviderConfigProperty.BOOLEAN_TYPE); configProperties.add(identityFirstproperty); I wanted to keep a default value as true and at first it seemed like the following line would do it: property.setDefaultValue(true); But that does not seem to work. The default is still false. How can I set the default to true? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160718/1c0294f8/attachment.html From sthorger at redhat.com Tue Jul 19 01:48:24 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 19 Jul 2016 07:48:24 +0200 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: <20160718224830.GA4459@abstractj.org> References: <20160718224830.GA4459@abstractj.org> Message-ID: Looks like it's better to keep as is and have user federation provider validate otp credentials as well. The current OTP authenticator delegates to user federation provider, so you'd end up with a separate OTP authenticator to do it with PAM. On 19 July 2016 at 00:48, Bruno Oliveira wrote: > Good morning, > > > Today to authentication against PAM with just simple username/password I > implemented UserFederationProvider and added the proper PAM login to > validCredentials[1]. This covers the most basic scenario. > > Now I would like to cover a more complex scenario like OTP and change > the flow a little bit like this: > > 1. User providers her username > 2. The next screen asks to provide how many factor our user has(For > example: OTP, password). We just don't know, PAM will tell what's next. > 3. We authenticate against it > > To see in practice against FreeIPA server, I just recorded it > for a practical example[2]. > > What would be the best approach to implement this flow? I was considering > to > move my authentication logic out of SSSD federation provider and create a > PAM > authenticator. > > Does it make sense? > > [1] - > http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > 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/20160719/162a3eea/attachment-0001.html From sthorger at redhat.com Tue Jul 19 01:51:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 19 Jul 2016 07:51:50 +0200 Subject: [keycloak-dev] Preferred storage mechanism for custom settings In-Reply-To: <1468874146.6797.11.camel@cargosoft.ru> References: <1468323778.4229.4.camel@cargosoft.ru> <1468607337.4292.5.camel@cargosoft.ru> <1468874146.6797.11.camel@cargosoft.ru> Message-ID: On 18 July 2016 at 22:35, Dmitry Telegin wrote: > Stian, > > Here we go: https://issues.jboss.org/browse/KEYCLOAK-3327 > > If the fix is somewhat trivial (i.e. a matter of adding fields and > getters/setters) I think I could work on a PR as well. > As the attributes are already available in the underlying entities it's just a matter of exposing through RealmModel and add tests for it. > > BTW, does this mean that all the custom entities provided via Entity SPI > are not by default cache-enabled (and won't be synchronized between the > nodes in clustered environment)? > If so, will it be easy to cache-enable them? Is this just a matter of > providing Infinispan adapters similar to existing ones for > Realm/User/Role/Client etc.? > There's no caching for custom entities. I'd recommend using Hibernate 2nd level cache for it as it's rather tricky to create a custom one. We have our custom one because we need to support Mongo as well as users from different sources (user federation and identity brokering). > > Ideally, I'd like to see a current domain-extension example augmented with > Infinispan cache functionality. I've got some ideas on a detailed > walkthrough tutorial for building complete, full-featured KeyCloak > extensions (it's a big topic I'll elaborate on a bit later); I think > Infinispan-enabled entities could be covered there, too. > No chance we're adding cache for custom entities. It's just to hard to get right. For custom entities you should use Hibernate 2nd level cache. > > Regards, > Dmitry > > ? ??, 18/07/2016 ? 07:39 +0200, Stian Thorgersen ?????: > > Forgot that attributes are not exposed through RealmModel. You can't > access the JPA RealmAdapter directly as you'll break the cache > functionality. You can create a JIRA to request attributes added to > RealmModel though. > > On 15 July 2016 at 20:28, Mitya wrote: > > Stian, > > In my provider, session.getContext().getRealm() returns an instance > of org.keycloak.models.cache.infinispan.RealmAdapter. But in order to be > able to manage attributes, we need an org.keycloak.models.jpa.RealmAdapter. > What's the best way to obtain it? > > I've yet come up with the following: > > RealmModel realm = session.getContext().getRealm(); > RealmAdapter adapter = (RealmAdapter) > session.getProvider(RealmProvider.class).getRealm(realm.getId()); > > > Realm attributes should be perfect for that > > On 12 July 2016 at 13:42, Mitya wrote: > > Hi, > > I'm developing a KeyCloak extension, and I want some custom (per-realm) > parameters to be tuned via the GUI form. Speaking of the storage mechanism > for my settings, are realm attributes suitable for that? or should I create > a dedicated custom entity instead? > > Thx, > Mitya > > _______________________________________________ > 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/20160719/63aed2aa/attachment.html From sthorger at redhat.com Tue Jul 19 04:02:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 19 Jul 2016 10:02:48 +0200 Subject: [keycloak-dev] Feedback on authz services Message-ID: Things we could add: ---------------------------- * Add policy enforcement support to Keycloak Proxy * Node.js adapter Comments: --------------- * Docs - added a few comments ( https://www.gitbook.com/book/keycloak/authorization-services-guide/discussions ) * JS Policy - I found it hard to figure out how to write these, especially since the docs are showing Java interfaces * Attribute based policy - We don't seem to have a simple attribute based policy, should we not have this? * Default policy (only from realm) - This default makes no sense. I'd suggest removing or replacing with something that's more obvious like "require user to have an email set" * Time policy - what about date/time ranges (Mon-Fri, 9am to 17pm, 18-20th June, etc..) * Evaluate in console - this is a bit awkward to use. I propose we add a "view example token" option to clients that can be used to show how a token would look like for a specific user. This would be useful when figuring out protocol mappers, etc.. Then we could piggy back on this feature in the evaluation so "real" values from a token could be used when testing policies rather than having to manually add all values. This is especially relevant to abac based policies. * Role policy - can only select realm level roles. What about client roles? * Scope - is scope not already a very overused term? Could we call this actions, operations or something else? * Usability - it's easier to find policies and resources on the tabs than it is when creating a permission. Maybe we could add a modal panel that helps to find resources and policies? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160719/0e0ce8a3/attachment.html From bruno at abstractj.org Tue Jul 19 05:00:35 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 19 Jul 2016 06:00:35 -0300 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: References: <20160718224830.GA4459@abstractj.org> Message-ID: <20160719090035.GB4459@abstractj.org> The problem here is the fact that not necessarily the first factor will be a pasword or the second factor an OTP. It could be a smartcard for example. That's why I think is a better idea to make it dynamic, because we don't have control over it to tell if the second factor will be a smartcard or an OTP for example. Does it make sense? On 2016-07-19, Stian Thorgersen wrote: > Looks like it's better to keep as is and have user federation provider > validate otp credentials as well. The current OTP authenticator delegates > to user federation provider, so you'd end up with a separate OTP > authenticator to do it with PAM. > > On 19 July 2016 at 00:48, Bruno Oliveira wrote: > > > Good morning, > > > > > > Today to authentication against PAM with just simple username/password I > > implemented UserFederationProvider and added the proper PAM login to > > validCredentials[1]. This covers the most basic scenario. > > > > Now I would like to cover a more complex scenario like OTP and change > > the flow a little bit like this: > > > > 1. User providers her username > > 2. The next screen asks to provide how many factor our user has(For > > example: OTP, password). We just don't know, PAM will tell what's next. > > 3. We authenticate against it > > > > To see in practice against FreeIPA server, I just recorded it > > for a practical example[2]. > > > > What would be the best approach to implement this flow? I was considering > > to > > move my authentication logic out of SSSD federation provider and create a > > PAM > > authenticator. > > > > Does it make sense? > > > > [1] - > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Jul 19 05:13:31 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 19 Jul 2016 06:13:31 -0300 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true In-Reply-To: References: Message-ID: <20160719091331.GC4459@abstractj.org> Hi Rashmi, try "true" instead of true. Take a look at this: https://github.com/keycloak/keycloak/blob/f6a718f10a3a3a07a6222bea7d8b58e13712479c/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/federation/DummyConfigurableUserFederationProviderFactory.java#L53-L58 In theory, should work. On 2016-07-18, Rashmi Singh wrote: > In my AuthenticatorFactory class, I have the following configuration added: > > ProviderConfigProperty property; > property= new ProviderConfigProperty(); > property.setName("propname"); > property.setLabel("Property Name"); > property.setDefaultValue(true); > property.setType(ProviderConfigProperty.BOOLEAN_TYPE); > configProperties.add(identityFirstproperty); > > I wanted to keep a default value as true and at first it seemed like the > following line would do it: > > property.setDefaultValue(true); > > But that does not seem to work. The default is still false. How can I set > the default to true? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From sthorger at redhat.com Tue Jul 19 07:25:29 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 19 Jul 2016 13:25:29 +0200 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: <20160719090035.GB4459@abstractj.org> References: <20160718224830.GA4459@abstractj.org> <20160719090035.GB4459@abstractj.org> Message-ID: Adding Bill.. It would probably still be better to use user federation for verifying credentials, but we would need some logic on how to determine what mechanism to use for primary authentication and secondary authentication. Bill was talking about adding some conditional flows to the authentication maybe that's what we need. For now I'd focus on OTP though and then move on to smartcard afterwards. On 19 July 2016 at 11:00, Bruno Oliveira wrote: > The problem here is the fact that not necessarily the > first factor will be a pasword or the second factor an OTP. It > could be a smartcard for example. That's why I think is a better idea to > make it dynamic, because we don't have control over it to tell > if the second factor will be a smartcard or an OTP for example. > > Does it make sense? > > On 2016-07-19, Stian Thorgersen wrote: > > Looks like it's better to keep as is and have user federation provider > > validate otp credentials as well. The current OTP authenticator delegates > > to user federation provider, so you'd end up with a separate OTP > > authenticator to do it with PAM. > > > > On 19 July 2016 at 00:48, Bruno Oliveira wrote: > > > > > Good morning, > > > > > > > > > Today to authentication against PAM with just simple username/password > I > > > implemented UserFederationProvider and added the proper PAM login to > > > validCredentials[1]. This covers the most basic scenario. > > > > > > Now I would like to cover a more complex scenario like OTP and change > > > the flow a little bit like this: > > > > > > 1. User providers her username > > > 2. The next screen asks to provide how many factor our user has(For > > > example: OTP, password). We just don't know, PAM will tell what's next. > > > 3. We authenticate against it > > > > > > To see in practice against FreeIPA server, I just recorded it > > > for a practical example[2]. > > > > > > What would be the best approach to implement this flow? I was > considering > > > to > > > move my authentication logic out of SSSD federation provider and > create a > > > PAM > > > authenticator. > > > > > > Does it make sense? > > > > > > [1] - > > > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160719/f92c3f68/attachment-0001.html From singhrasster at gmail.com Tue Jul 19 08:00:38 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Tue, 19 Jul 2016 07:00:38 -0500 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true In-Reply-To: <20160719091331.GC4459@abstractj.org> References: <20160719091331.GC4459@abstractj.org> Message-ID: Bruno, I had tried "true" also but that did not work either. Forgot to mention in my original post. I am not sure why true or "true" doesn't work if that's expected. Is there a bug? Does anyone have a clue on this? On Tue, Jul 19, 2016 at 4:13 AM, Bruno Oliveira wrote: > Hi Rashmi, try "true" instead of true. Take a look at this: > https://github.com/keycloak/keycloak/blob/f6a718f10a3a3a07a6222bea7d8b58e13712479c/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/federation/DummyConfigurableUserFederationProviderFactory.java#L53-L58 > > In theory, should work. > > On 2016-07-18, Rashmi Singh wrote: > > In my AuthenticatorFactory class, I have the following configuration > added: > > > > ProviderConfigProperty property; > > property= new ProviderConfigProperty(); > > property.setName("propname"); > > property.setLabel("Property Name"); > > property.setDefaultValue(true); > > property.setType(ProviderConfigProperty.BOOLEAN_TYPE); > > configProperties.add(identityFirstproperty); > > > > I wanted to keep a default value as true and at first it seemed like the > > following line would do it: > > > > property.setDefaultValue(true); > > > > But that does not seem to work. The default is still false. How can I set > > the default to true? > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160719/adce5230/attachment.html From psilva at redhat.com Tue Jul 19 08:41:48 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 19 Jul 2016 08:41:48 -0400 (EDT) Subject: [keycloak-dev] Feedback on authz services In-Reply-To: References: Message-ID: <237704280.14818352.1468932108804.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stian Thorgersen" > To: "Pedro Igor Silva" , "keycloak-dev" > Sent: Tuesday, July 19, 2016 5:02:48 AM > Subject: Feedback on authz services > > Things we could add: > ---------------------------- > > * Add policy enforcement support to Keycloak Proxy > > * Node.js adapter https://issues.jboss.org/browse/KEYCLOAK-3333 https://issues.jboss.org/browse/KEYCLOAK-3334 > > > Comments: > --------------- > > * Docs - added a few comments ( > https://www.gitbook.com/book/keycloak/authorization-services-guide/discussions > ) Will look at that. > > * JS Policy - I found it hard to figure out how to write these, especially > since the docs are showing Java interfaces Basically, we publish instances of those interfaces to the JS engine. That is why I did that way. If you know the contract, than you can start writing your policies. But I understand your point, I'm going to improve that doc and make it more JS-friendly. > > * Attribute based policy - We don't seem to have a simple attribute based > policy, should we not have this? Yes, that makes sense. https://issues.jboss.org/browse/KEYCLOAK-3335 > > * Default policy (only from realm) - This default makes no sense. I'd > suggest removing or replacing with something that's more obvious like > "require user to have an email set" I was thinking about that and, IMO, the rule you suggested is not the best way to go. As you know, users may not have an e-mail set, thus they won't be able to access applications protected with our policy enforcer. I think we can just have a simple policy that always perform a grant. The motivations behind that policy are: * Show that you can use rule-based policies * Show that we have an API that you can use to build these policies * Show that you can perform decisions based on attributes from both environment and identity (ABAC) Although redundant, that policy is a good start point to understand some capabilities we provide. > > * Time policy - what about date/time ranges (Mon-Fri, 9am to 17pm, 18-20th > June, etc..) Yes, that makes sense. https://issues.jboss.org/browse/KEYCLOAK-3337 > > * Evaluate in console - this is a bit awkward to use. I propose we add a > "view example token" option to clients that can be used to show how a token > would look like for a specific user. This would be useful when figuring out > protocol mappers, etc.. Then we could piggy back on this feature in the > evaluation so "real" values from a token could be used when testing > policies rather than having to manually add all values. This is especially > relevant to abac based policies. Recently, I've changed the evaluation service to re-use the protocol mappers configured to the client. That means, that the evaluation is now building a token similar to the real one. I think now we can easily introduce the UI to "view the example" token. As well the resulting token with the permissions. > > * Role policy - can only select realm level roles. What about client roles? https://issues.jboss.org/browse/KEYCLOAK-3338 > > * Scope - is scope not already a very overused term? Could we call this > actions, operations or something else? We have discussed that already. Based on Marek's feedback, I've changed the tab name to "Authorization Scopes". I don't like the term Action or Operation. IMO, we should stick with "Authorization Scopes"/"Scopes". > > * Usability - it's easier to find policies and resources on the tabs than > it is when creating a permission. Maybe we could add a modal panel that > helps to find resources and policies? We can have that. But I would also keep current UI to select a policy. > From sthorger at redhat.com Tue Jul 19 09:44:53 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 19 Jul 2016 15:44:53 +0200 Subject: [keycloak-dev] Feedback on authz services In-Reply-To: <237704280.14818352.1468932108804.JavaMail.zimbra@redhat.com> References: <237704280.14818352.1468932108804.JavaMail.zimbra@redhat.com> Message-ID: On 19 July 2016 at 14:41, Pedro Igor Silva wrote: > ----- Original Message ----- > > From: "Stian Thorgersen" > > To: "Pedro Igor Silva" , "keycloak-dev" < > keycloak-dev at lists.jboss.org> > > Sent: Tuesday, July 19, 2016 5:02:48 AM > > Subject: Feedback on authz services > > > > Things we could add: > > ---------------------------- > > > > * Add policy enforcement support to Keycloak Proxy > > > > * Node.js adapter > > https://issues.jboss.org/browse/KEYCLOAK-3333 > https://issues.jboss.org/browse/KEYCLOAK-3334 > > > > > > > Comments: > > --------------- > > > > * Docs - added a few comments ( > > > https://www.gitbook.com/book/keycloak/authorization-services-guide/discussions > > ) > > Will look at that. > > > > > * JS Policy - I found it hard to figure out how to write these, > especially > > since the docs are showing Java interfaces > > Basically, we publish instances of those interfaces to the JS engine. That > is why I did that way. If you know the contract, than you can start writing > your policies. > > But I understand your point, I'm going to improve that doc and make it > more JS-friendly. > > > > > * Attribute based policy - We don't seem to have a simple attribute based > > policy, should we not have this? > > Yes, that makes sense. https://issues.jboss.org/browse/KEYCLOAK-3335 > > > > > * Default policy (only from realm) - This default makes no sense. I'd > > suggest removing or replacing with something that's more obvious like > > "require user to have an email set" > > I was thinking about that and, IMO, the rule you suggested is not the best > way to go. As you know, users may not have an e-mail set, thus they won't > be able to access applications protected with our policy enforcer. I think > we can just have a simple policy that always perform a grant. > > The motivations behind that policy are: > > * Show that you can use rule-based policies > * Show that we have an API that you can use to build these policies > * Show that you can perform decisions based on attributes from both > environment and identity (ABAC) > > Although redundant, that policy is a good start point to understand some > capabilities we provide. > Current one isn't just redundant it's also confusing and slightly broken (realm name alone isn't sufficient as it could have been the same realm name on a different server). So IMO it should definitively be replaced, but I'm less bothered about what as long as it's obvious what the new example does. > > > > > * Time policy - what about date/time ranges (Mon-Fri, 9am to 17pm, > 18-20th > > June, etc..) > > Yes, that makes sense. > > https://issues.jboss.org/browse/KEYCLOAK-3337 > > > > > * Evaluate in console - this is a bit awkward to use. I propose we add a > > "view example token" option to clients that can be used to show how a > token > > would look like for a specific user. This would be useful when figuring > out > > protocol mappers, etc.. Then we could piggy back on this feature in the > > evaluation so "real" values from a token could be used when testing > > policies rather than having to manually add all values. This is > especially > > relevant to abac based policies. > > Recently, I've changed the evaluation service to re-use the protocol > mappers configured to the client. That means, that the evaluation is now > building a token similar to the real one. > > I think now we can easily introduce the UI to "view the example" token. As > well the resulting token with the permissions. > > > > > * Role policy - can only select realm level roles. What about client > roles? > > https://issues.jboss.org/browse/KEYCLOAK-3338 > > > > > * Scope - is scope not already a very overused term? Could we call this > > actions, operations or something else? > > We have discussed that already. Based on Marek's feedback, I've changed > the tab name to "Authorization Scopes". > > I don't like the term Action or Operation. IMO, we should stick with > "Authorization Scopes"/"Scopes". > OK > > > > > * Usability - it's easier to find policies and resources on the tabs than > > it is when creating a permission. Maybe we could add a modal panel that > > helps to find resources and policies? > > We can have that. But I would also keep current UI to select a policy. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160719/bb5e41d2/attachment.html From singhrasster at gmail.com Tue Jul 19 10:23:49 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Tue, 19 Jul 2016 09:23:49 -0500 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true In-Reply-To: References: <20160719091331.GC4459@abstractj.org> Message-ID: Infact, not only Boolean, it does not seem to work for even properties that are STRING_TYPE. I was using 1.9.4 version earlier but now I tried with the latest 2.0.0 version too and it does not work on either. What is the issue? On Tue, Jul 19, 2016 at 7:00 AM, Rashmi Singh wrote: > Bruno, I had tried "true" also but that did not work either. Forgot to > mention in my original post. I am not sure why true or "true" doesn't work > if that's expected. Is there a bug? Does anyone have a clue on this? > > On Tue, Jul 19, 2016 at 4:13 AM, Bruno Oliveira > wrote: > >> Hi Rashmi, try "true" instead of true. Take a look at this: >> https://github.com/keycloak/keycloak/blob/f6a718f10a3a3a07a6222bea7d8b58e13712479c/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/federation/DummyConfigurableUserFederationProviderFactory.java#L53-L58 >> >> In theory, should work. >> >> On 2016-07-18, Rashmi Singh wrote: >> > In my AuthenticatorFactory class, I have the following configuration >> added: >> > >> > ProviderConfigProperty property; >> > property= new ProviderConfigProperty(); >> > property.setName("propname"); >> > property.setLabel("Property Name"); >> > property.setDefaultValue(true); >> > property.setType(ProviderConfigProperty.BOOLEAN_TYPE); >> > configProperties.add(identityFirstproperty); >> > >> > I wanted to keep a default value as true and at first it seemed like the >> > following line would do it: >> > >> > property.setDefaultValue(true); >> > >> > But that does not seem to work. The default is still false. How can I >> set >> > the default to true? >> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160719/44ffb555/attachment-0001.html From sthorger at redhat.com Wed Jul 20 01:35:18 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 20 Jul 2016 07:35:18 +0200 Subject: [keycloak-dev] Move tools from testsuite/integration into testsuite/tools Message-ID: We're migrating all tests from testsuite/integration to testsuite/integration-arquillian. Once all tests have been migrated we can remove the old testsuite, but there are also some tools in there that are useful during development. Unless anyone objects I'll move KeycloakServer, MailServer and TotpGenerator into a new component testsuite/tools. We should also move util/embedded-ldap there as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160720/55320a9c/attachment.html From sthorger at redhat.com Wed Jul 20 02:04:24 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 20 Jul 2016 08:04:24 +0200 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true In-Reply-To: References: <20160719091331.GC4459@abstractj.org> Message-ID: It looks like the default value is only used in the admin console to show a default value for the option when configuring the authenticator. The default values are not added to AuthenticationFlowContext.getAuthenticatorConfig unless the authenticator is first configured through the admin console. It would be better if it was though so default values would always be available. Feel free to create an enhancement JIRA issue for it. On 19 July 2016 at 16:23, Rashmi Singh wrote: > Infact, not only Boolean, it does not seem to work for even properties > that are STRING_TYPE. I was using 1.9.4 version earlier but now I tried > with the latest 2.0.0 version too and it does not work on either. What is > the issue? > > On Tue, Jul 19, 2016 at 7:00 AM, Rashmi Singh > wrote: > >> Bruno, I had tried "true" also but that did not work either. Forgot to >> mention in my original post. I am not sure why true or "true" doesn't work >> if that's expected. Is there a bug? Does anyone have a clue on this? >> >> On Tue, Jul 19, 2016 at 4:13 AM, Bruno Oliveira >> wrote: >> >>> Hi Rashmi, try "true" instead of true. Take a look at this: >>> https://github.com/keycloak/keycloak/blob/f6a718f10a3a3a07a6222bea7d8b58e13712479c/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/federation/DummyConfigurableUserFederationProviderFactory.java#L53-L58 >>> >>> In theory, should work. >>> >>> On 2016-07-18, Rashmi Singh wrote: >>> > In my AuthenticatorFactory class, I have the following configuration >>> added: >>> > >>> > ProviderConfigProperty property; >>> > property= new ProviderConfigProperty(); >>> > property.setName("propname"); >>> > property.setLabel("Property Name"); >>> > property.setDefaultValue(true); >>> > property.setType(ProviderConfigProperty.BOOLEAN_TYPE); >>> > configProperties.add(identityFirstproperty); >>> > >>> > I wanted to keep a default value as true and at first it seemed like >>> the >>> > following line would do it: >>> > >>> > property.setDefaultValue(true); >>> > >>> > But that does not seem to work. The default is still false. How can I >>> set >>> > the default to true? >>> >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> >> >> > > _______________________________________________ > 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/20160720/b2bcfbde/attachment.html From singhrasster at gmail.com Wed Jul 20 03:12:34 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Wed, 20 Jul 2016 02:12:34 -0500 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true In-Reply-To: References: <20160719091331.GC4459@abstractj.org> Message-ID: For now, I want the default value to show up in the admin console only when looking at the config of the authenticator. The issue is that the default value I am setting for the properties in authenticatorFactory are not showing up on the admin console when you look at the authenticator -> config. I see the properties displayed there but they dont show the default values I set in the factory class. For booleans, it always show false and for string types, always blank and not what I set. I am not looking for the default values in AuthenticationFlowContext.getAuthenticatorConfig. I am looking for it in the admin console only. I expected this to work but it doesn't. Is it a bug? On Wed, Jul 20, 2016 at 1:04 AM, Stian Thorgersen wrote: > It looks like the default value is only used in the admin console to show > a default value for the option when configuring the authenticator. The > default values are not added to > AuthenticationFlowContext.getAuthenticatorConfig unless the authenticator > is first configured through the admin console. It would be better if it was > though so default values would always be available. Feel free to create an > enhancement JIRA issue for it. > > On 19 July 2016 at 16:23, Rashmi Singh wrote: > >> Infact, not only Boolean, it does not seem to work for even properties >> that are STRING_TYPE. I was using 1.9.4 version earlier but now I tried >> with the latest 2.0.0 version too and it does not work on either. What is >> the issue? >> >> On Tue, Jul 19, 2016 at 7:00 AM, Rashmi Singh >> wrote: >> >>> Bruno, I had tried "true" also but that did not work either. Forgot to >>> mention in my original post. I am not sure why true or "true" doesn't work >>> if that's expected. Is there a bug? Does anyone have a clue on this? >>> >>> On Tue, Jul 19, 2016 at 4:13 AM, Bruno Oliveira >>> wrote: >>> >>>> Hi Rashmi, try "true" instead of true. Take a look at this: >>>> https://github.com/keycloak/keycloak/blob/f6a718f10a3a3a07a6222bea7d8b58e13712479c/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/federation/DummyConfigurableUserFederationProviderFactory.java#L53-L58 >>>> >>>> In theory, should work. >>>> >>>> On 2016-07-18, Rashmi Singh wrote: >>>> > In my AuthenticatorFactory class, I have the following configuration >>>> added: >>>> > >>>> > ProviderConfigProperty property; >>>> > property= new ProviderConfigProperty(); >>>> > property.setName("propname"); >>>> > property.setLabel("Property Name"); >>>> > property.setDefaultValue(true); >>>> > property.setType(ProviderConfigProperty.BOOLEAN_TYPE); >>>> > configProperties.add(identityFirstproperty); >>>> > >>>> > I wanted to keep a default value as true and at first it seemed like >>>> the >>>> > following line would do it: >>>> > >>>> > property.setDefaultValue(true); >>>> > >>>> > But that does not seem to work. The default is still false. How can I >>>> set >>>> > the default to true? >>>> >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> -- >>>> >>>> abstractj >>>> PGP: 0x84DC9914 >>>> >>> >>> >> >> _______________________________________________ >> 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/20160720/d4d8a2a6/attachment.html From swananddhawan at arvindinternet.com Wed Jul 20 03:14:42 2016 From: swananddhawan at arvindinternet.com (swanand dhawan) Date: Wed, 20 Jul 2016 12:44:42 +0530 Subject: [keycloak-dev] Keycloak build failing at "Keycloak Security Proxy TestSuite" stage Message-ID: Hello, I am getting the following error while building Keycloak for the *first* time. ``Failed to execute goal on project keycloak-testsuite-security-proxy: *Could not resolve dependencies for project org.keycloak:keycloak-testsuite-security-proxy:jar:2.1.0-SNAPSHOT: Failure to find org.keycloak:keycloak-testsuite-integration:jar:tests:2.1.0-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public/ * was cached in the local repository, resolution will not be reattempted until the update interval of jboss has elapsed or updates are forced`` How can I fix it? -- Thanks & Regards, Swanand Dhawan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160720/c7fdd337/attachment-0001.html From sthorger at redhat.com Wed Jul 20 03:16:46 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 20 Jul 2016 09:16:46 +0200 Subject: [keycloak-dev] Authorization Code Flow as Default for Javascript? In-Reply-To: References: Message-ID: Using authorization code flow with public clients in Keycloak: * Allows short expiration on access tokens * Our JavaScript adapter doesn't store the refresh token and it's only kept in memory for the specific tab * Refresh tokens are tied to a session which have idle timeout Access token is set to expire in 5 min by default, but a lot of damage can still be done in 5 min so it needs to be kept secure. Refresh token is obviously worse as it, but by default the user session will expire if idle for 30 min so all refresh tokens will be invalid shortly after the user leaves the browser. Google for instance issues an access token with 60 minutes expiration this is far worse than what we do in Keycloak as the token can't be revoked. Applications are not required to check with Google if the token is still valid, so there's a window of 60 minutes where it would be rather hard to block miss-use. It's actually common for social networks at least to issue fairly long expiration times (an hour or so) when using the implicit flow. You could in theory use an embedded iframe to obtain a new access token once it's expired, but this is relatively tricky to get right as there's quite a lot of potentially vulnerabilities which is why we by default block all use of iframes. Any malicious injected code that manages to get the refresh token from the tab window would also be able to use the embedded iframe to obtain a new access token. There is a spec that allows authenticating public clients. I couldn't find it right now, but probably something worth considering to add. On 18 July 2016 at 19:19, Josh Cain wrote: > Thanks for the quick response Stian! Still getting my feet wet with OIDC, > so please bear with me as I try to reconcile what I'm reading @ the spec > with the Keycloak implementation. A few questions on your response: > > You say that it's 'usual' for these access tokens to have a long lifespan > with implicit flow. How does that interact with the general guideline in > section 16.18 of the spec when it says: > > Access Tokens might not be revocable by the Authorization Server. Access >> Token lifetimes SHOULD therefore be kept to single use or very short >> lifetimes. > > > I would agree that a long-lived refresh token is indeed much preferred to > doing something like extending the lifetime of an access token. However, > is 'the OAuth redirect dance' the only alternative? I know that Keycloak's > identity/session cookies will have been issued at this point - would it be > possible to use something like an iFrame to refresh a short-lived access > token? > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > On Wed, Jul 13, 2016 at 1:37 AM, Stian Thorgersen > wrote: > >> With Implicit flow it's usual to have a long expiration on access tokens >> as there is no refresh token. Once the access token is expired you're left >> with having to do the whole OAuth redirect dance again to obtain a new >> token. What's even worse is that if you have long lived access tokens >> there's potentially a longer time between the verification of >> the access token directly with Keycloak, which means that an access token >> could potentially be used long after the session has been removed. >> >> With that in mind having short lived access tokens with a refresh token >> is better in our opinion even for public clients. >> >> On 12 July 2016 at 19:22, Josh Cain wrote: >> >>> Hi All, >>> >>> We're looking to start rolling the Keycloak OIDC flow out to some >>> client-side Javascript applications, and I came across a question in coming >>> up to speed on OIDC. You state in your docs >>> >>> that the Javascript adapter is intended for client-side use: >>> >>> Keycloak comes with a client-side JavaScript library that can be used to >>>> secure HTML5/JavaScript applications. >>>> >>> >>> The docs also state that the default flow for this adapter is the >>> Authorization Code flow: >>> >>> By default, the JavaScript adapter uses the Authorization Code >>>> >>>> flow. >>>> >>> >>> However, the OIDC spec >>> says (section >>> 3.1): >>> >>> ...The Authorization Code flow is suitable for Clients that can securely >>>> maintain a Client Secret between themselves and the Authorization Server. >>>> >>> >>> And again echoes the sentiment using the non-requisite MAY language in >>> section 15.4: >>> >>> In general, it is up to Relying Parties which features they use when >>>> interacting with OpenID Providers. However, some choices are dictated by >>>> the nature of their OAuth Client, such as whether it is a Confidential >>>> Client, capable of keeping secrets, in which case the Authorization Code >>>> Flow may be appropriate, or whether it is a Public Client, for instance, a >>>> User Agent Based Application or a statically registered Native Application, >>>> in which case the Implicit Flow may be appropriate. >>>> >>> >>> I'm aware that public clients who do not present a client secret are >>> allowed under the OAuth spec , and >>> that these are often the type of javascript client that Keycloak sets up >>> with the authorization code flow. What's more, I understand that the >>> client secret is most commonly the reason cited for the client/server >>> distinction with respect to flows. >>> >>> However, I was curious as to why the authorization code flow remains the >>> default setting for Javascript applications. Isn't the refresh token also >>> considered a form of a 'secret' since it's a long-lived mechanism whereby >>> additional access/identity tokens can be retrieved? Why would the default >>> setting *not* be implicit here? Could you help me understand why the >>> authorization code flow was chosen as the default? >>> >>> Thanks in advance! >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 843-737-1735 >>> >>> _______________________________________________ >>> 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/20160720/ea736007/attachment.html From thomas.darimont at googlemail.com Wed Jul 20 03:50:55 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 20 Jul 2016 09:50:55 +0200 Subject: [keycloak-dev] Keycloak build failing at "Keycloak Security Proxy TestSuite" stage In-Reply-To: References: Message-ID: Hello, try: mvn clean install -U -U will update the snapshots - you probably tried to build while a CI Build updated the libraries. If you don't want to run the tests you can append: -DskipTests If you want to build on multiple CPU cores add: -T 2.0C Cheers, Thomas 2016-07-20 9:14 GMT+02:00 swanand dhawan : > Hello, > > I am getting the following error while building Keycloak for the *first* > time. > ``Failed to execute goal on project keycloak-testsuite-security-proxy: *Could > not resolve dependencies for project > org.keycloak:keycloak-testsuite-security-proxy:jar:2.1.0-SNAPSHOT: Failure > to find > org.keycloak:keycloak-testsuite-integration:jar:tests:2.1.0-SNAPSHOT in > http://repository.jboss.org/nexus/content/groups/public/ > * was cached in > the local repository, resolution will not be reattempted until the update > interval of jboss has elapsed or updates are forced`` > > How can I fix it? > > -- > Thanks & Regards, > Swanand Dhawan > > _______________________________________________ > 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/20160720/05c8b794/attachment.html From swananddhawan at arvindinternet.com Wed Jul 20 05:15:49 2016 From: swananddhawan at arvindinternet.com (swanand dhawan) Date: Wed, 20 Jul 2016 14:45:49 +0530 Subject: [keycloak-dev] Keycloak build failing at "Keycloak Security Proxy TestSuite" stage In-Reply-To: References: Message-ID: Hello Thomas, I did `mvn clean install -U` and it fixed my problem! Thanks for the help! On Wed, Jul 20, 2016 at 1:20 PM, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello, > > try: mvn clean install -U > -U will update the snapshots - you probably tried to build while a CI > Build updated the libraries. > > If you don't want to run the tests you can append: -DskipTests > If you want to build on multiple CPU cores add: -T 2.0C > > > Cheers, > Thomas > > 2016-07-20 9:14 GMT+02:00 swanand dhawan >: > >> Hello, >> >> I am getting the following error while building Keycloak for the *first* >> time. >> ``Failed to execute goal on project keycloak-testsuite-security-proxy: *Could >> not resolve dependencies for project >> org.keycloak:keycloak-testsuite-security-proxy:jar:2.1.0-SNAPSHOT: Failure >> to find >> org.keycloak:keycloak-testsuite-integration:jar:tests:2.1.0-SNAPSHOT in >> http://repository.jboss.org/nexus/content/groups/public/ >> * was cached >> in the local repository, resolution will not be reattempted until the >> update interval of jboss has elapsed or updates are forced`` >> >> How can I fix it? >> >> -- >> Thanks & Regards, >> Swanand Dhawan >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- Thanks & Regards, Swanand Dhawan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160720/20b6e43a/attachment-0001.html From bruno at abstractj.org Wed Jul 20 10:06:07 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 20 Jul 2016 11:06:07 -0300 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: References: <20160718224830.GA4459@abstractj.org> <20160719090035.GB4459@abstractj.org> Message-ID: <20160720140607.GA24947@abstractj.org> On 2016-07-19, Stian Thorgersen wrote: > Adding Bill.. > > It would probably still be better to use user federation for verifying > credentials, but we would need some logic on how to determine what > mechanism to use for primary authentication and secondary authentication. > Bill was talking about adding some conditional flows to the authentication > maybe that's what we need. > > For now I'd focus on OTP though and then move on to smartcard afterwards. I can give it a try and workaround, but I'm not sure if worth the effort, assuming that later will be necessary to revisit. If we hardcode/workaround it on Keycloak, user's coming from FreeIPA may have their login denied. Even if we ignore smartcards for now. Why? Depending on the auth types SSSD will show different login prompts. For example: * Password Login prompt - $ Password: * OTP Login prompt -> $ First factor: $ Second factor: Note: Please notice that they are not validated separately * Password + OTP -> $ First factor or password: That's the reason why I would like to make the our login screen dynamic. > > On 19 July 2016 at 11:00, Bruno Oliveira wrote: > > > The problem here is the fact that not necessarily the > > first factor will be a pasword or the second factor an OTP. It > > could be a smartcard for example. That's why I think is a better idea to > > make it dynamic, because we don't have control over it to tell > > if the second factor will be a smartcard or an OTP for example. > > > > Does it make sense? > > > > On 2016-07-19, Stian Thorgersen wrote: > > > Looks like it's better to keep as is and have user federation provider > > > validate otp credentials as well. The current OTP authenticator delegates > > > to user federation provider, so you'd end up with a separate OTP > > > authenticator to do it with PAM. > > > > > > On 19 July 2016 at 00:48, Bruno Oliveira wrote: > > > > > > > Good morning, > > > > > > > > > > > > Today to authentication against PAM with just simple username/password > > I > > > > implemented UserFederationProvider and added the proper PAM login to > > > > validCredentials[1]. This covers the most basic scenario. > > > > > > > > Now I would like to cover a more complex scenario like OTP and change > > > > the flow a little bit like this: > > > > > > > > 1. User providers her username > > > > 2. The next screen asks to provide how many factor our user has(For > > > > example: OTP, password). We just don't know, PAM will tell what's next. > > > > 3. We authenticate against it > > > > > > > > To see in practice against FreeIPA server, I just recorded it > > > > for a practical example[2]. > > > > > > > > What would be the best approach to implement this flow? I was > > considering > > > > to > > > > move my authentication logic out of SSSD federation provider and > > create a > > > > PAM > > > > authenticator. > > > > > > > > Does it make sense? > > > > > > > > [1] - > > > > > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > > > > > > > > > -- > > > > > > > > abstractj > > > > PGP: 0x84DC9914 > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Wed Jul 20 11:12:34 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 20 Jul 2016 11:12:34 -0400 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: <20160720140607.GA24947@abstractj.org> References: <20160718224830.GA4459@abstractj.org> <20160719090035.GB4459@abstractj.org> <20160720140607.GA24947@abstractj.org> Message-ID: Just create a different form and new Authenticator. I don't think we want all this logic with Freemarker, do we? The UI is decoupled from credential validation on purpose so that you can move things around, i.e. a Username screen, then the next screen is password/OTP input. Another thing you could do is collect credentials and store them in the ClientSessionModel, then once you've collected the credentials, validate them all in one go. On 7/20/16 10:06 AM, Bruno Oliveira wrote: > On 2016-07-19, Stian Thorgersen wrote: >> Adding Bill.. >> >> It would probably still be better to use user federation for verifying >> credentials, but we would need some logic on how to determine what >> mechanism to use for primary authentication and secondary authentication. >> Bill was talking about adding some conditional flows to the authentication >> maybe that's what we need. >> >> For now I'd focus on OTP though and then move on to smartcard afterwards. > I can give it a try and workaround, but I'm not sure if worth the > effort, assuming that later will be necessary to revisit. > > If we hardcode/workaround it on Keycloak, user's coming from FreeIPA > may have their login denied. Even if we ignore smartcards for now. Why? > > Depending on the auth types SSSD will show different login prompts. For > example: > > * Password > Login prompt - $ Password: > > * OTP > Login prompt -> $ First factor: > $ Second factor: > Note: Please notice that they are not validated separately > > * Password + OTP -> $ First factor or password: > > That's the reason why I would like to make the our login screen > dynamic. > >> On 19 July 2016 at 11:00, Bruno Oliveira wrote: >> >>> The problem here is the fact that not necessarily the >>> first factor will be a pasword or the second factor an OTP. It >>> could be a smartcard for example. That's why I think is a better idea to >>> make it dynamic, because we don't have control over it to tell >>> if the second factor will be a smartcard or an OTP for example. >>> >>> Does it make sense? >>> >>> On 2016-07-19, Stian Thorgersen wrote: >>>> Looks like it's better to keep as is and have user federation provider >>>> validate otp credentials as well. The current OTP authenticator delegates >>>> to user federation provider, so you'd end up with a separate OTP >>>> authenticator to do it with PAM. >>>> >>>> On 19 July 2016 at 00:48, Bruno Oliveira wrote: >>>> >>>>> Good morning, >>>>> >>>>> >>>>> Today to authentication against PAM with just simple username/password >>> I >>>>> implemented UserFederationProvider and added the proper PAM login to >>>>> validCredentials[1]. This covers the most basic scenario. >>>>> >>>>> Now I would like to cover a more complex scenario like OTP and change >>>>> the flow a little bit like this: >>>>> >>>>> 1. User providers her username >>>>> 2. The next screen asks to provide how many factor our user has(For >>>>> example: OTP, password). We just don't know, PAM will tell what's next. >>>>> 3. We authenticate against it >>>>> >>>>> To see in practice against FreeIPA server, I just recorded it >>>>> for a practical example[2]. >>>>> >>>>> What would be the best approach to implement this flow? I was >>> considering >>>>> to >>>>> move my authentication logic out of SSSD federation provider and >>> create a >>>>> PAM >>>>> authenticator. >>>>> >>>>> Does it make sense? >>>>> >>>>> [1] - >>>>> >>> http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- >>>>> [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a >>>>> >>>>> >>>>> -- >>>>> >>>>> abstractj >>>>> PGP: 0x84DC9914 >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> > -- > > abstractj > PGP: 0x84DC9914 From bruno at abstractj.org Wed Jul 20 11:23:09 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 20 Jul 2016 12:23:09 -0300 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: References: <20160718224830.GA4459@abstractj.org> <20160719090035.GB4459@abstractj.org> <20160720140607.GA24947@abstractj.org> Message-ID: <20160720152309.GB24947@abstractj.org> Thanks Bill, that helped. Will give it a try. On 2016-07-20, Bill Burke wrote: > Just create a different form and new Authenticator. I don't think we want > all this logic with Freemarker, do we? The UI is decoupled from credential > validation on purpose so that you can move things around, i.e. a Username > screen, then the next screen is password/OTP input. > > Another thing you could do is collect credentials and store them in the > ClientSessionModel, then once you've collected the credentials, validate > them all in one go. > > On 7/20/16 10:06 AM, Bruno Oliveira wrote: > > On 2016-07-19, Stian Thorgersen wrote: > > > Adding Bill.. > > > > > > It would probably still be better to use user federation for verifying > > > credentials, but we would need some logic on how to determine what > > > mechanism to use for primary authentication and secondary authentication. > > > Bill was talking about adding some conditional flows to the authentication > > > maybe that's what we need. > > > > > > For now I'd focus on OTP though and then move on to smartcard afterwards. > > I can give it a try and workaround, but I'm not sure if worth the > > effort, assuming that later will be necessary to revisit. > > > > If we hardcode/workaround it on Keycloak, user's coming from FreeIPA > > may have their login denied. Even if we ignore smartcards for now. Why? > > > > Depending on the auth types SSSD will show different login prompts. For > > example: > > > > * Password > > Login prompt - $ Password: > > > > * OTP > > Login prompt -> $ First factor: > > $ Second factor: > > Note: Please notice that they are not validated separately > > > > * Password + OTP -> $ First factor or password: > > > > That's the reason why I would like to make the our login screen > > dynamic. > > > > > On 19 July 2016 at 11:00, Bruno Oliveira wrote: > > > > > > > The problem here is the fact that not necessarily the > > > > first factor will be a pasword or the second factor an OTP. It > > > > could be a smartcard for example. That's why I think is a better idea to > > > > make it dynamic, because we don't have control over it to tell > > > > if the second factor will be a smartcard or an OTP for example. > > > > > > > > Does it make sense? > > > > > > > > On 2016-07-19, Stian Thorgersen wrote: > > > > > Looks like it's better to keep as is and have user federation provider > > > > > validate otp credentials as well. The current OTP authenticator delegates > > > > > to user federation provider, so you'd end up with a separate OTP > > > > > authenticator to do it with PAM. > > > > > > > > > > On 19 July 2016 at 00:48, Bruno Oliveira wrote: > > > > > > > > > > > Good morning, > > > > > > > > > > > > > > > > > > Today to authentication against PAM with just simple username/password > > > > I > > > > > > implemented UserFederationProvider and added the proper PAM login to > > > > > > validCredentials[1]. This covers the most basic scenario. > > > > > > > > > > > > Now I would like to cover a more complex scenario like OTP and change > > > > > > the flow a little bit like this: > > > > > > > > > > > > 1. User providers her username > > > > > > 2. The next screen asks to provide how many factor our user has(For > > > > > > example: OTP, password). We just don't know, PAM will tell what's next. > > > > > > 3. We authenticate against it > > > > > > > > > > > > To see in practice against FreeIPA server, I just recorded it > > > > > > for a practical example[2]. > > > > > > > > > > > > What would be the best approach to implement this flow? I was > > > > considering > > > > > > to > > > > > > move my authentication logic out of SSSD federation provider and > > > > create a > > > > > > PAM > > > > > > authenticator. > > > > > > > > > > > > Does it make sense? > > > > > > > > > > > > [1] - > > > > > > > > > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > abstractj > > > > > > PGP: 0x84DC9914 > > > > > > _______________________________________________ > > > > > > keycloak-dev mailing list > > > > > > keycloak-dev at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > -- > > > > > > > > abstractj > > > > PGP: 0x84DC9914 > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > -- abstractj PGP: 0x84DC9914 From mitya at cargosoft.ru Wed Jul 20 14:52:06 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Wed, 20 Jul 2016 21:52:06 +0300 Subject: [keycloak-dev] Applying post-create realm modifications Message-ID: <1469040726.4229.17.camel@cargosoft.ru> Hi, A KeyCloak extension might have a need to apply customizations to a newly created realm, be it master realm on a first-time run, or a realm added later via admin console. From my practice, I can mention at least two use cases for that: 1. Creating a custom authentication flow. If you provide a custom authenticator, you might also want to provide a custom flow for it, thus making it usable out-of-the-box, and without having an end-user dive deep into the details of flow setup; 2. Creating custom admin roles, i.e. atomic "view-something" and "manage-something" roles belonging to a *-realm client of master-realm (and automatically joining the realm "admin" role). This might be topical if you provide a custom realm resource, and you want to secure it with individual roles different from the built-in ones. There is a RealmModel.RealmCreationEvent?event fired from JpaRealmProvider. Unfortunately, it is fired too early; it delivers a realm instance in its bare, non-initialized state which is unusable for both of the above use cases: - adding custom authentication flow at this moment will break further realm initialization logic, as latter relies on the emptiness of the flow container; - adding roles simply wouldn't work because no clients (including the desired *-realm) are yet registered with the realm. It would be nice to have something like RealmCreatedEvent (maybe inside RealmManager) that would be fired just before RealmManager::createRealm returns. Should be as trivial as adding an inner class/interface and firing an event. Regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160720/5b5fe4c7/attachment.html From bburke at redhat.com Wed Jul 20 15:26:07 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 20 Jul 2016 15:26:07 -0400 Subject: [keycloak-dev] Applying post-create realm modifications In-Reply-To: <1469040726.4229.17.camel@cargosoft.ru> References: <1469040726.4229.17.camel@cargosoft.ru> Message-ID: +1. Name the event RealmPostCreateEvent. I was also thinking of having a FeatureProvider that would be an "uber" component that could install sub components. i.e. an authenticator, user federation provider, etc. Interested in contributing? On 7/20/16 2:52 PM, Dmitry Telegin wrote: > Hi, > > A KeyCloak extension might have a need to apply customizations to a > newly created realm, be it master realm on a first-time run, or a > realm added later via admin console. From my practice, I can mention > at least two use cases for that: > > 1. Creating a custom authentication flow. If you provide a custom > authenticator, you might also want to provide a custom flow for it, > thus making it usable out-of-the-box, and without having an end-user > dive deep into the details of flow setup; > 2. Creating custom admin roles, i.e. atomic "view-something" and > "manage-something" roles belonging to a *-realm client of master-realm > (and automatically joining the realm "admin" role). This might be > topical if you provide a custom realm resource, and you want to secure > it with individual roles different from the built-in ones. > > There is a RealmModel.RealmCreationEvent event fired from > JpaRealmProvider. Unfortunately, it is fired too early; it delivers a > realm instance in its bare, non-initialized state which is unusable > for both of the above use cases: > - adding custom authentication flow at this moment will break further > realm initialization logic, as latter relies on the emptiness of the > flow container; > - adding roles simply wouldn't work because no clients (including the > desired *-realm) are yet registered with the realm. > > It would be nice to have something like RealmCreatedEvent (maybe > inside RealmManager) that would be fired just before > RealmManager::createRealm returns. Should be as trivial as adding an > inner class/interface and firing an event. > > Regards, > Dmitry > > > > _______________________________________________ > 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/20160720/256a6219/attachment-0001.html From mitya at cargosoft.ru Wed Jul 20 19:11:22 2016 From: mitya at cargosoft.ru (Dmitry Telegin) Date: Thu, 21 Jul 2016 02:11:22 +0300 Subject: [keycloak-dev] Applying post-create realm modifications In-Reply-To: References: <1469040726.4229.17.camel@cargosoft.ru> Message-ID: <1469056282.6804.28.camel@cargosoft.ru> > > +1.? Name the event RealmPostCreateEvent.? OK, so I'll be filing now a JIRA issue and then a PR, right? > I was also thinking of > ??????having a FeatureProvider that would be an "uber" component that > ??????could install sub components.? i.e. an authenticator, user > ??????federation provider, etc. > ????Interested in contributing? Absolutely! This would be a perfect match for what I'm working on now. It's in beta at the moment, but I think a little disclosure won't hurt: it will be a device management add-on that will let KeyCloak manage hardware OTP generators (tokens). It implements full device lifecycle support, including bulk import (from a vendor-supplied XML file), maintaining a pool of available devices, enrollment/revocation etc. Here's a draft manual: https://dteleguin.gitbooks.io/keycloak-tms-ru/content/ (It's in Russian, so skip the text and look at screenshots, just to have an idea what's it all about.) Under the hood, it consists of custom JPA entity, custom REST resource, custom authenticator, a customized GUI theme, and a code to tweak newly created realms (hence this discussion). I think extensions like this would definitely benefit from some kind of umbrella construct, or "uber" component. I could even envision it becoming the base for plugin-like architecture and even plugin "market", similar to what we have in Atlassian products. I'm not mentioning Atlassian just because; KeyCloak and Atlassian Crowd are the same field players. Before KeyCloak came into existence, we had tried to implement similar device management system on top of Crowd - and had failed miserably, due to lack of documentation and extension points (that's not the case for JIRA and Confluence, obviously). Implementing the same on top of KeyCloak was orders of magnitude easier. Surely I've encountered some caveats; I think I'll do another ML post to summarize my experience, and maybe one day even will turn it into a walkthrough tutorial for creating full-featured KeyCloak extensions. Cheers, Dmitry > > > > > > > On 7/20/16 2:52 PM, Dmitry Telegin wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > A KeyCloak extension might have a need to apply customizations to a newly created realm, be it master realm on a first-time run, or a realm added later via admin console. From my practice, I can mention at least two use cases for that: > > > > 1. Creating a custom authentication flow. If you provide a custom authenticator, you might also want to provide a custom flow for it, thus making it usable out-of-the-box, and without having an end-user dive deep into the details of flow setup; > > 2. Creating custom admin roles, i.e. atomic "view-something" and "manage-something" roles belonging to a *-realm client of master-realm (and automatically joining the realm "admin" role). This might be topical if you provide a custom realm resource, and you want to secure it with individual roles different from the built-in ones. > > > > There is a RealmModel.RealmCreationEvent?event fired from JpaRealmProvider. Unfortunately, it is fired too early; it delivers a realm instance in its bare, non-initialized state which is unusable for both of the above use cases: > > - adding custom authentication flow at this moment will break further realm initialization logic, as latter relies on the emptiness of the flow container; > > - adding roles simply wouldn't work because no clients (including the desired *-realm) are yet registered with the realm. > > > > It would be nice to have something like RealmCreatedEvent (maybe inside RealmManager) that would be fired just before RealmManager::createRealm returns. Should be as trivial as adding an inner class/interface and firing an event. > > > > Regards, > > Dmitry > > > > > > _______________________________________________ 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/20160721/89d02731/attachment.html From sthorger at redhat.com Thu Jul 21 08:18:56 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 21 Jul 2016 14:18:56 +0200 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true In-Reply-To: References: <20160719091331.GC4459@abstractj.org> Message-ID: Looks like a bug then - Bill any comments? On 20 July 2016 at 09:12, Rashmi Singh wrote: > For now, I want the default value to show up in the admin console only > when looking at the config of the authenticator. The issue is that the > default value I am setting for the properties in authenticatorFactory are > not showing up on the admin console when you look at the authenticator -> > config. I see the properties displayed there but they dont show the default > values I set in the factory class. For booleans, it always show false and > for string types, always blank and not what I set. I am not looking for the > default values in AuthenticationFlowContext.getAuthenticatorConfig. I am > looking for it in the admin console only. I expected this to work but it > doesn't. Is it a bug? > > On Wed, Jul 20, 2016 at 1:04 AM, Stian Thorgersen > wrote: > >> It looks like the default value is only used in the admin console to show >> a default value for the option when configuring the authenticator. The >> default values are not added to >> AuthenticationFlowContext.getAuthenticatorConfig unless the authenticator >> is first configured through the admin console. It would be better if it was >> though so default values would always be available. Feel free to create an >> enhancement JIRA issue for it. >> >> On 19 July 2016 at 16:23, Rashmi Singh wrote: >> >>> Infact, not only Boolean, it does not seem to work for even properties >>> that are STRING_TYPE. I was using 1.9.4 version earlier but now I tried >>> with the latest 2.0.0 version too and it does not work on either. What is >>> the issue? >>> >>> On Tue, Jul 19, 2016 at 7:00 AM, Rashmi Singh >>> wrote: >>> >>>> Bruno, I had tried "true" also but that did not work either. Forgot to >>>> mention in my original post. I am not sure why true or "true" doesn't work >>>> if that's expected. Is there a bug? Does anyone have a clue on this? >>>> >>>> On Tue, Jul 19, 2016 at 4:13 AM, Bruno Oliveira >>>> wrote: >>>> >>>>> Hi Rashmi, try "true" instead of true. Take a look at this: >>>>> https://github.com/keycloak/keycloak/blob/f6a718f10a3a3a07a6222bea7d8b58e13712479c/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/federation/DummyConfigurableUserFederationProviderFactory.java#L53-L58 >>>>> >>>>> In theory, should work. >>>>> >>>>> On 2016-07-18, Rashmi Singh wrote: >>>>> > In my AuthenticatorFactory class, I have the following configuration >>>>> added: >>>>> > >>>>> > ProviderConfigProperty property; >>>>> > property= new ProviderConfigProperty(); >>>>> > property.setName("propname"); >>>>> > property.setLabel("Property Name"); >>>>> > property.setDefaultValue(true); >>>>> > property.setType(ProviderConfigProperty.BOOLEAN_TYPE); >>>>> > configProperties.add(identityFirstproperty); >>>>> > >>>>> > I wanted to keep a default value as true and at first it seemed like >>>>> the >>>>> > following line would do it: >>>>> > >>>>> > property.setDefaultValue(true); >>>>> > >>>>> > But that does not seem to work. The default is still false. How can >>>>> I set >>>>> > the default to true? >>>>> >>>>> > _______________________________________________ >>>>> > keycloak-dev mailing list >>>>> > keycloak-dev at lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> -- >>>>> >>>>> abstractj >>>>> PGP: 0x84DC9914 >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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/20160721/75e8f2ec/attachment.html From sthorger at redhat.com Thu Jul 21 10:06:20 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 21 Jul 2016 16:06:20 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI Message-ID: Great work Marko! As we didn't have time to go through feedback let's use this thread for it. Add your questions and comments here please. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160721/0db131ef/attachment.html From bburke at redhat.com Thu Jul 21 10:25:02 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 21 Jul 2016 10:25:02 -0400 Subject: [keycloak-dev] Applying post-create realm modifications In-Reply-To: <1469056282.6804.28.camel@cargosoft.ru> References: <1469040726.4229.17.camel@cargosoft.ru> <1469056282.6804.28.camel@cargosoft.ru> Message-ID: <8682abe6-aac2-901c-7a23-7f029c413bf5@redhat.com> On 7/20/16 7:11 PM, Dmitry Telegin wrote: >> >> +1. Name the event RealmPostCreateEvent. >> > > OK, so I'll be filing now a JIRA issue and then a PR, right? > Yes. >> I was also thinking of having a FeatureProvider that would be an >> "uber" component that could install sub components. i.e. an >> authenticator, user federation provider, etc. >> >> Interested in contributing? >> > > Absolutely! This would be a perfect match for what I'm working on now. > It's in beta at the moment, but I think a little disclosure won't > hurt: it will be a device management add-on that will let KeyCloak > manage hardware OTP generators (tokens). It implements full device > lifecycle support, including bulk import (from a vendor-supplied XML > file), maintaining a pool of available devices, enrollment/revocation > etc. Here's a draft manual: > > https://dteleguin.gitbooks.io/keycloak-tms-ru/content/ > > (It's in Russian, so skip the text and look at screenshots, just to > have an idea what's it all about.) > > Under the hood, it consists of custom JPA entity, custom REST > resource, custom authenticator, a customized GUI theme, and a code to > tweak newly created realms (hence this discussion). I think extensions > like this would definitely benefit from some kind of umbrella > construct, or "uber" component. I could even envision it becoming the > base for plugin-like architecture and even plugin "market", similar to > what we have in Atlassian products. > Lets get some requirements going on the FeatureProvider in separate. Your devices thing looks interesting too and we should discuss in a separate thread. From mstrukel at redhat.com Thu Jul 21 10:47:48 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 21 Jul 2016 16:47:48 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: Message-ID: And if anyone wants to get their feet wet already: https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen wrote: > Great work Marko! > > As we didn't have time to go through feedback let's use this thread for > it. Add your questions and comments here please. > > _______________________________________________ > 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/20160721/35599261/attachment.html From bburke at redhat.com Thu Jul 21 11:04:19 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 21 Jul 2016 11:04:19 -0400 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: Message-ID: <22c5bf45-0fbb-3e96-4e37-037328c9bf32@redhat.com> Looks good. Are we going to have similar CLI efforts to manage other parts of the server? On 7/21/16 10:47 AM, Marko Strukelj wrote: > And if anyone wants to get their feet wet already: > > https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool > > > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen > wrote: > > Great work Marko! > > As we didn't have time to go through feedback let's use this > thread for it. Add your questions and comments here please. > > _______________________________________________ > 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/20160721/64c4778e/attachment.html From mstrukel at redhat.com Thu Jul 21 11:16:37 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 21 Jul 2016 17:16:37 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: <22c5bf45-0fbb-3e96-4e37-037328c9bf32@redhat.com> References: <22c5bf45-0fbb-3e96-4e37-037328c9bf32@redhat.com> Message-ID: Yes, I'll start working on Admin CLI soon. I'll put together a design document for it first. On Thu, Jul 21, 2016 at 5:04 PM, Bill Burke wrote: > Looks good. Are we going to have similar CLI efforts to manage other > parts of the server? > > On 7/21/16 10:47 AM, Marko Strukelj wrote: > > And if anyone wants to get their feet wet already: > > > https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool > > > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen > wrote: > >> Great work Marko! >> >> As we didn't have time to go through feedback let's use this thread for >> it. Add your questions and comments here please. >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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/20160721/f2b5ea52/attachment.html From bruno at abstractj.org Thu Jul 21 13:15:09 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 21 Jul 2016 14:15:09 -0300 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: Message-ID: <20160721171509.GA22848@abstractj.org> Nice work Marko! I had two (not big deal) questions. First, when you specify the --cache parameters as you did for SAML, could the cache file be omitted? For example: kcreg --cache -r saml-realm ... I was thinking that once you specified the realm name, the API will just look for ~/.keycloak/saml-realm.cache. It's just an idea. Second question, is more like something to think if worth to take into consideration. Most of the examples that I saw, make use of username/password. But if the admin enables two factor authentication, she might be unable to use our client-reg CLI, or enforce weaken security only to make use of the CLI. Is OTP support planned for further iterations? On 2016-07-21, Marko Strukelj wrote: > And if anyone wants to get their feet wet already: > > https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool > > > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen > wrote: > > > Great work Marko! > > > > As we didn't have time to go through feedback let's use this thread for > > it. Add your questions and comments here please. > > > > _______________________________________________ > > 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 -- abstractj PGP: 0x84DC9914 From singhrasster at gmail.com Thu Jul 21 20:03:37 2016 From: singhrasster at gmail.com (Rashmi Singh) Date: Thu, 21 Jul 2016 19:03:37 -0500 Subject: [keycloak-dev] How to set default value of a boolean ProviderConfigProperty to true In-Reply-To: References: <20160719091331.GC4459@abstractj.org> Message-ID: Please confirm that this is a bug. If yes, can we have this fixed? We really wanted this feature in our project ASAP. Please let me know what can be done about this. On Thu, Jul 21, 2016 at 7:18 AM, Stian Thorgersen wrote: > Looks like a bug then - Bill any comments? > > On 20 July 2016 at 09:12, Rashmi Singh wrote: > >> For now, I want the default value to show up in the admin console only >> when looking at the config of the authenticator. The issue is that the >> default value I am setting for the properties in authenticatorFactory are >> not showing up on the admin console when you look at the authenticator -> >> config. I see the properties displayed there but they dont show the default >> values I set in the factory class. For booleans, it always show false and >> for string types, always blank and not what I set. I am not looking for the >> default values in AuthenticationFlowContext.getAuthenticatorConfig. I >> am looking for it in the admin console only. I expected this to work but it >> doesn't. Is it a bug? >> >> On Wed, Jul 20, 2016 at 1:04 AM, Stian Thorgersen >> wrote: >> >>> It looks like the default value is only used in the admin console to >>> show a default value for the option when configuring the authenticator. The >>> default values are not added to >>> AuthenticationFlowContext.getAuthenticatorConfig unless the authenticator >>> is first configured through the admin console. It would be better if it was >>> though so default values would always be available. Feel free to create an >>> enhancement JIRA issue for it. >>> >>> On 19 July 2016 at 16:23, Rashmi Singh wrote: >>> >>>> Infact, not only Boolean, it does not seem to work for even properties >>>> that are STRING_TYPE. I was using 1.9.4 version earlier but now I tried >>>> with the latest 2.0.0 version too and it does not work on either. What is >>>> the issue? >>>> >>>> On Tue, Jul 19, 2016 at 7:00 AM, Rashmi Singh >>>> wrote: >>>> >>>>> Bruno, I had tried "true" also but that did not work either. Forgot to >>>>> mention in my original post. I am not sure why true or "true" doesn't work >>>>> if that's expected. Is there a bug? Does anyone have a clue on this? >>>>> >>>>> On Tue, Jul 19, 2016 at 4:13 AM, Bruno Oliveira >>>>> wrote: >>>>> >>>>>> Hi Rashmi, try "true" instead of true. Take a look at this: >>>>>> https://github.com/keycloak/keycloak/blob/f6a718f10a3a3a07a6222bea7d8b58e13712479c/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/federation/DummyConfigurableUserFederationProviderFactory.java#L53-L58 >>>>>> >>>>>> In theory, should work. >>>>>> >>>>>> On 2016-07-18, Rashmi Singh wrote: >>>>>> > In my AuthenticatorFactory class, I have the following >>>>>> configuration added: >>>>>> > >>>>>> > ProviderConfigProperty property; >>>>>> > property= new ProviderConfigProperty(); >>>>>> > property.setName("propname"); >>>>>> > property.setLabel("Property Name"); >>>>>> > property.setDefaultValue(true); >>>>>> > property.setType(ProviderConfigProperty.BOOLEAN_TYPE); >>>>>> > configProperties.add(identityFirstproperty); >>>>>> > >>>>>> > I wanted to keep a default value as true and at first it seemed >>>>>> like the >>>>>> > following line would do it: >>>>>> > >>>>>> > property.setDefaultValue(true); >>>>>> > >>>>>> > But that does not seem to work. The default is still false. How can >>>>>> I set >>>>>> > the default to true? >>>>>> >>>>>> > _______________________________________________ >>>>>> > keycloak-dev mailing list >>>>>> > keycloak-dev at lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> abstractj >>>>>> PGP: 0x84DC9914 >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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/20160721/eb670970/attachment-0001.html From sthorger at redhat.com Fri Jul 22 03:26:59 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 22 Jul 2016 09:26:59 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: <20160721171509.GA22848@abstractj.org> References: <20160721171509.GA22848@abstractj.org> Message-ID: It should be fairly easy to add support for OTP as well as the direct grant supports that. The user would have to specify to use OTP though. On 21 July 2016 at 19:15, Bruno Oliveira wrote: > Nice work Marko! I had two (not big deal) questions. First, when you > specify the --cache parameters as you did for SAML, could the cache file > be omitted? > > For example: kcreg --cache -r saml-realm ... > > I was thinking that once you specified the realm name, the API will just > look for ~/.keycloak/saml-realm.cache. It's just an idea. > > Second question, is more like something to think if worth to take > into consideration. Most of the examples that I saw, make use of > username/password. But if the admin enables two factor authentication, > she might be unable to use our client-reg CLI, or enforce weaken security > only > to make use of the CLI. > > Is OTP support planned for further iterations? > > > On 2016-07-21, Marko Strukelj wrote: > > And if anyone wants to get their feet wet already: > > > > > https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool > > > > > > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen > > wrote: > > > > > Great work Marko! > > > > > > As we didn't have time to go through feedback let's use this thread for > > > it. Add your questions and comments here please. > > > > > > _______________________________________________ > > > 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 > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/82af5718/attachment.html From sthorger at redhat.com Fri Jul 22 03:33:51 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 22 Jul 2016 09:33:51 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: A few questions from me: * Is it possible to view the returned JSON when creating and updating a client? This contains values filled in by the server, including the registration access token. * Should we not enable pretty print by default? * --cache isn't the most intuitive name, I don't have a better suggestion though * Docs should be moved to Gitbook "Securing Clients and Applications guide" * When creating clients and later updating them I assume it uses the registration access token from the cache? * A nice addition would be the ability to list attributes from ClientRepresentation so it's easy to discover what attributes can be set * What about setting/changing complex attributes, how does that look like? Can we add/remove to an array? Add/remove elements to a complex object? Something like JSON patch could be nice https://tools.ietf.org/html/rfc6902 On 22 July 2016 at 09:26, Stian Thorgersen wrote: > It should be fairly easy to add support for OTP as well as the direct > grant supports that. The user would have to specify to use OTP though. > > On 21 July 2016 at 19:15, Bruno Oliveira wrote: > >> Nice work Marko! I had two (not big deal) questions. First, when you >> specify the --cache parameters as you did for SAML, could the cache file >> be omitted? >> >> For example: kcreg --cache -r saml-realm ... >> >> I was thinking that once you specified the realm name, the API will just >> look for ~/.keycloak/saml-realm.cache. It's just an idea. >> >> Second question, is more like something to think if worth to take >> into consideration. Most of the examples that I saw, make use of >> username/password. But if the admin enables two factor authentication, >> she might be unable to use our client-reg CLI, or enforce weaken security >> only >> to make use of the CLI. >> >> Is OTP support planned for further iterations? >> >> >> On 2016-07-21, Marko Strukelj wrote: >> > And if anyone wants to get their feet wet already: >> > >> > >> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool >> > >> > >> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen >> > wrote: >> > >> > > Great work Marko! >> > > >> > > As we didn't have time to go through feedback let's use this thread >> for >> > > it. Add your questions and comments here please. >> > > >> > > _______________________________________________ >> > > 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 >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/3be6c1b8/attachment.html From sthorger at redhat.com Fri Jul 22 03:40:20 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 22 Jul 2016 09:40:20 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: One more: * How should we distribute it? I propose we just add kcreg.sh/kcreg.bat + the JAR to the bin directory of the server On 22 July 2016 at 09:33, Stian Thorgersen wrote: > A few questions from me: > > * Is it possible to view the returned JSON when creating and updating a > client? This contains values filled in by the server, including the > registration access token. > * Should we not enable pretty print by default? > * --cache isn't the most intuitive name, I don't have a better suggestion > though > * Docs should be moved to Gitbook "Securing Clients and Applications guide" > * When creating clients and later updating them I assume it uses the > registration access token from the cache? > * A nice addition would be the ability to list attributes from > ClientRepresentation so it's easy to discover what attributes can be set > * What about setting/changing complex attributes, how does that look like? > Can we add/remove to an array? Add/remove elements to a complex object? > Something like JSON patch could be nice > https://tools.ietf.org/html/rfc6902 > > On 22 July 2016 at 09:26, Stian Thorgersen wrote: > >> It should be fairly easy to add support for OTP as well as the direct >> grant supports that. The user would have to specify to use OTP though. >> >> On 21 July 2016 at 19:15, Bruno Oliveira wrote: >> >>> Nice work Marko! I had two (not big deal) questions. First, when you >>> specify the --cache parameters as you did for SAML, could the cache file >>> be omitted? >>> >>> For example: kcreg --cache -r saml-realm ... >>> >>> I was thinking that once you specified the realm name, the API will just >>> look for ~/.keycloak/saml-realm.cache. It's just an idea. >>> >>> Second question, is more like something to think if worth to take >>> into consideration. Most of the examples that I saw, make use of >>> username/password. But if the admin enables two factor authentication, >>> she might be unable to use our client-reg CLI, or enforce weaken >>> security only >>> to make use of the CLI. >>> >>> Is OTP support planned for further iterations? >>> >>> >>> On 2016-07-21, Marko Strukelj wrote: >>> > And if anyone wants to get their feet wet already: >>> > >>> > >>> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool >>> > >>> > >>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen >> > >>> > wrote: >>> > >>> > > Great work Marko! >>> > > >>> > > As we didn't have time to go through feedback let's use this thread >>> for >>> > > it. Add your questions and comments here please. >>> > > >>> > > _______________________________________________ >>> > > 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 >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/224e2592/attachment.html From sthorger at redhat.com Fri Jul 22 03:51:56 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 22 Jul 2016 09:51:56 +0200 Subject: [keycloak-dev] Keycloak Stats Message-ID: I wanted to share some Keycloak stats for July as I'm proud of what we've achieved: Website: * 8056 unique users in July * 700-800 visits per weekday * Users from pretty much everywhere around the world Downloads: * 1281 downloads of the server alone in July * 100K+ pulls of main Docker image from Docker Hub Github: * 7000+ commits * 124 contributors * 587 stars * 453 forks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/3820a8f0/attachment-0001.html From thomas.darimont at googlemail.com Fri Jul 22 04:21:18 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 22 Jul 2016 10:21:18 +0200 Subject: [keycloak-dev] Keycloak Stats In-Reply-To: References: Message-ID: With the voice sample of Quake3: Impressive! Am 22.07.2016 9:52 vorm. schrieb "Stian Thorgersen" : > I wanted to share some Keycloak stats for July as I'm proud of what we've > achieved: > > Website: > > * 8056 unique users in July > * 700-800 visits per weekday > * Users from pretty much everywhere around the world > > Downloads: > > * 1281 downloads of the server alone in July > * 100K+ pulls of main Docker image from Docker Hub > > Github: > > * 7000+ commits > * 124 contributors > * 587 stars > * 453 forks > > _______________________________________________ > 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/20160722/b648eae6/attachment.html From Stephen.Merchant at gandlake.com Fri Jul 22 04:56:54 2016 From: Stephen.Merchant at gandlake.com (Stephen Merchant) Date: Fri, 22 Jul 2016 08:56:54 +0000 Subject: [keycloak-dev] Keycloak Version 2.0.0 : MongoDB Start-up Issue. Message-ID: <3DE4BF1BF8EDD84B8F8D61B0A88BD563101C5D@EXCH01.gandlake.local> Hello, I am assessing standalone Keycloak version 2.0.0 configured for MongoDB Version 3.2.8 persistence. I have made configuration changes to ...\standalone\configuration\keycloak-server.json as advised here. On start-up : 1) I can see the keycloak database get created in my MongoDB instance. [cid:image002.png at 01D1E3FD.A17167D0] 2) On standalone Keycloak startup I get the exception detailed in the WildFly log snippet below. I would appreciate any advice or assistance you have to offer with this issue. Thank you. 09:41:00,981 INFO [org.mongodb.driver.connection] (ServerService Thread Pool -- 47) Opened connection [connectionId{localValue:2, serverValue:14}] to localhost:27017 09:41:01,625 WARN [org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory] (ServerService Thread Pool -- 47) Can't rollback connection: java.sql.SQLException: IJ031022: You cannot rollback with autocommit set at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1124) at org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:196) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:60) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:48) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) at org.keycloak.models.jpa.session.JpaUserSessionPersisterProviderFactory.create(JpaUserSessionPersisterProviderFactory.java:38) at org.keycloak.models.jpa.session.JpaUserSessionPersisterProviderFactory.create(JpaUserSessionPersisterProviderFactory.java:32) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) at org.keycloak.models.sessions.infinispan.initializer.OfflineUserSessionLoader.init(OfflineUserSessionLoader.java:38) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer$1.run(InfinispanUserSessionInitializer.java:110) at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.getOrCreateInitializerState(InfinispanUserSessionInitializer.java:107) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.startLoading(InfinispanUserSessionInitializer.java:158) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.loadPersistentSessions(InfinispanUserSessionInitializer.java:88) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$2.run(InfinispanUserSessionProviderFactory.java:91) at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory.loadPersistentSessions(InfinispanUserSessionProviderFactory.java:82) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$1.onEvent(InfinispanUserSessionProviderFactory.java:71) at org.keycloak.services.DefaultKeycloakSessionFactory.publish(DefaultKeycloakSessionFactory.java:64) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:130) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) 09:41:01,670 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 47) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) ... 6 more Caused by: java.lang.IllegalStateException: Trying to update database, but don't have a DB lock acquired at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:165) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:60) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:48) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) at org.keycloak.models.jpa.session.JpaUserSessionPersisterProviderFactory.create(JpaUserSessionPersisterProviderFactory.java:38) at org.keycloak.models.jpa.session.JpaUserSessionPersisterProviderFactory.create(JpaUserSessionPersisterProviderFactory.java:32) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) at org.keycloak.models.sessions.infinispan.initializer.OfflineUserSessionLoader.init(OfflineUserSessionLoader.java:38) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer$1.run(InfinispanUserSessionInitializer.java:110) at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.getOrCreateInitializerState(InfinispanUserSessionInitializer.java:107) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.startLoading(InfinispanUserSessionInitializer.java:158) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.loadPersistentSessions(InfinispanUserSessionInitializer.java:88) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$2.run(InfinispanUserSessionProviderFactory.java:91) at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory.loadPersistentSessions(InfinispanUserSessionProviderFactory.java:82) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$1.onEvent(InfinispanUserSessionProviderFactory.java:71) at org.keycloak.services.DefaultKeycloakSessionFactory.publish(DefaultKeycloakSessionFactory.java:64) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:130) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) ... 19 more 09:41:01,730 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "keycloak-server.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./auth" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.IllegalStateException: Trying to update database, but don't have a DB lock acquired"}} 09:41:01,775 INFO [org.jboss.as.server] (ServerService Thread Pool -- 44) WFLYSRV0010: Deployed "keycloak-server.war" (runtime-name : "keycloak-server.war") 09:41:01,779 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report WFLYCTL0186: Services which failed to start: service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) 09:41:01,997 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management 09:41:02,012 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 09:41:02,013 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: Keycloak 2.0.0.Final (WildFly Core 2.0.10.Final) started (with errors) in 7942ms - Started 414 of 799 services (2 services failed or missing dependencies, 542 services are lazy, passive or on-demand) Stephen Merchant Developer Gandlake Limited Crown Commercial Service Supplier BSI ISO/IEC 27001 certification number IS 585161 Gandlake Limited, a Limited Liability Company registered in England and Wales under number 4667925. Registered Office: Gandlake House, London Road, Newbury, Berkshire. RG14 1LA. VAT Registration Number 809 7164 11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/22d90dee/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11984 bytes Desc: image002.png Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/22d90dee/attachment-0001.png From mstrukel at redhat.com Fri Jul 22 05:37:07 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 Jul 2016 11:37:07 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: <20160721171509.GA22848@abstractj.org> References: <20160721171509.GA22848@abstractj.org> Message-ID: On Thu, Jul 21, 2016 at 7:15 PM, Bruno Oliveira wrote: > Nice work Marko! I had two (not big deal) questions. First, when you > specify the --cache parameters as you did for SAML, could the cache file > be omitted? > > For example: kcreg --cache -r saml-realm ... > > I was thinking that once you specified the realm name, the API will just > look for ~/.keycloak/saml-realm.cache. It's just an idea We could maybe add this behaviour in addition to current behaviour. It's not enough to just specify a realm though, since server can also be different. For example: # login as admin user in master realm on localhost using default cache file (~/.keycloak/kcreg.cache) kcreg login -s http://localhost:8080/auth -r master -u admin # login as admin user in master realm on login.example.com using a different cache file kcreg --cache ~/.keycloak/example_com.cache login -s http://login.example.com -r master -u admin Using kcreg --cache -r master ... as above would default to the same file (~/.keycloak/master.cache) unless we also include server_endpoint in the file name e.g.: localhost_8080_auth_master.cache. But then - login command gets the server specified by user. Not so with other commands. The current mechanism reads the server from the specified cache file (the server for current session it's stored inside a JSON): kcreg --cache ~/.keycloak/localhost_8080_auth_master.cache get my_client So your proposal is unable to determine the full name of the file - we need to know the server already to compose the file name: kcreg --cache -r master get my_client The above can resolve to ~/.keycloak/master.cache but doesn't have enough info to resolve to ~/.keycloak/localhost_8080_auth_master.cache. If we also have to specify server the result is not worth the bother: kcreg --cache -s http://localhost:8080/auth -r master get my_client Another thing - if we want to also support current behavior (which allows all the freedom and flexibility of choosing any location on the filesystem for the cache file) we would then need to treat additional argument to --cache as optional, which can quickly get tricky: kcreg --cache login -r master ... vs. kcreg --cache /tmp/session.cache -x login ... vs. kcreg --cache -r master get ... We could do that by checking if next argument begins with a '-' but that would disable usage of any filename starting with '-'. And we would have to treat it differently for login ... The more I look at it, the more complex and tricky it gets to get it right. One quite simple solution towards more ergonomic usage would be to simply differentiate whether the specified path is absolute or relative, and if relative we could default the directory to ~/.keycloak. For example: kcreg --cache master login -s http://localhost:8080/auth -r master -u admin This would generate the following cache file: ~/.keycloak/master.cache, and the folling command would use that file as well: kcreg --cache master get my_client The absolute names would be those starting with /, ~/ on unix, c:\, d:\ ... on Windows This behaviour is easy to add. > > Second question, is more like something to think if worth to take > into consideration. Most of the examples that I saw, make use of > username/password. But if the admin enables two factor authentication, > she might be unable to use our client-reg CLI, or enforce weaken security > only > to make use of the CLI. > > Is OTP support planned for further iterations? I don't know how exactly OTP auth works under the hood, but if Stian says it's no problem and it's easy to implement then that's your answer :) > > On 2016-07-21, Marko Strukelj wrote: > > And if anyone wants to get their feet wet already: > > > > > https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool > > > > > > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen > > wrote: > > > > > Great work Marko! > > > > > > As we didn't have time to go through feedback let's use this thread for > > > it. Add your questions and comments here please. > > > > > > _______________________________________________ > > > 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 > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/1d42005f/attachment.html From bruno at abstractj.org Fri Jul 22 05:51:24 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 22 Jul 2016 06:51:24 -0300 Subject: [keycloak-dev] Read-only attributes for UserFederation providers Message-ID: <20160722095124.GB27222@abstractj.org> Good morning, I was working on this issue[1] this week and thinking about how to tell our interface that the federation provider has read-only attributes. For example, today for the LDAPFederationProvider[2], we provide server side validations telling our user that they cannot edit those attributes. But still, input fields are editable and user will only know after hit the submit button. Not sure if makes sense, but very maybe if we provide a method at UserFederation like: boolean isReadOnly(); //defaults to false or override it and return true And later expose it to the interface, we could bring the text field properties set to read-only. Does it make any sense? [1] - https://issues.jboss.org/browse/KEYCLOAK-3060 [2] - https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/federation/ldap/src/main/java/org/keycloak/federation/ldap/ReadonlyLDAPUserModelDelegate.java#L38-L64 -- abstractj PGP: 0x84DC9914 From mstrukel at redhat.com Fri Jul 22 06:02:48 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 Jul 2016 12:02:48 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen wrote: > A few questions from me: > > * Is it possible to view the returned JSON when creating and updating a > client? This contains values filled in by the server, including the > registration access token. > Not ATM. I can add an option e.g. -o, --output Display the new state of client configuration. > * Should we not enable pretty print by default? > I suppose that would be more user friendly. Just don't know how to name the switch -p, --pretty is so obvious ... > * --cache isn't the most intuitive name, I don't have a better suggestion > though > OpenShift client uses the term configuration rather than cache, and uses --config accordingly. We could do the same, and even add 'kcreg config' command to inspect and edit the config file if we deem that necessary. * Docs should be moved to Gitbook "Securing Clients and Applications guide" > The only doc currently is the README file, so I guess that's the one you mean. I'd wait a bit with adding it to docbook. The later I make a copy in Gitbook the less double work will there be editing the changes. > * When creating clients and later updating them I assume it uses the > registration access token from the cache? > Yes. If it can't find one it uses bearer token from login. > * A nice addition would be the ability to list attributes from > ClientRepresentation so it's easy to discover what attributes can be set > That's trivial to add using reflection. But how would the UI look? Ideally we'd have tab completion for this at some point. Something like this? $ kcreg list-attrs clientId String redirectUris List baseUrl String enabled Boolean ... $ kcreg list-attrs -e oidc redirect_uris List grant_types List However if we want to be more specific, with some additional help on the meaning, and possible values, then we would need to annotate Representation classes with the necessary info, or simply have a help-style static text. > * What about setting/changing complex attributes, how does that look like? > Can we add/remove to an array? Add/remove elements to a complex object? > Something like JSON patch could be nice > https://tools.ietf.org/html/rfc6902 > I haven't gone so far with this iteration. That's a TODO. > > On 22 July 2016 at 09:26, Stian Thorgersen wrote: > >> It should be fairly easy to add support for OTP as well as the direct >> grant supports that. The user would have to specify to use OTP though. >> >> On 21 July 2016 at 19:15, Bruno Oliveira wrote: >> >>> Nice work Marko! I had two (not big deal) questions. First, when you >>> specify the --cache parameters as you did for SAML, could the cache file >>> be omitted? >>> >>> For example: kcreg --cache -r saml-realm ... >>> >>> I was thinking that once you specified the realm name, the API will just >>> look for ~/.keycloak/saml-realm.cache. It's just an idea. >>> >>> Second question, is more like something to think if worth to take >>> into consideration. Most of the examples that I saw, make use of >>> username/password. But if the admin enables two factor authentication, >>> she might be unable to use our client-reg CLI, or enforce weaken >>> security only >>> to make use of the CLI. >>> >>> Is OTP support planned for further iterations? >>> >>> >>> On 2016-07-21, Marko Strukelj wrote: >>> > And if anyone wants to get their feet wet already: >>> > >>> > >>> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool >>> > >>> > >>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen >> > >>> > wrote: >>> > >>> > > Great work Marko! >>> > > >>> > > As we didn't have time to go through feedback let's use this thread >>> for >>> > > it. Add your questions and comments here please. >>> > > >>> > > _______________________________________________ >>> > > 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 >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/0fbf2282/attachment-0001.html From bruno at abstractj.org Fri Jul 22 06:05:03 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 22 Jul 2016 07:05:03 -0300 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: <20160722100503.GC27222@abstractj.org> If changing the interface is going to be tricky, just ignore my idea. I haven't played with it yet, so any suggestion will be really inaccurate :) On 2016-07-22, Marko Strukelj wrote: > On Thu, Jul 21, 2016 at 7:15 PM, Bruno Oliveira wrote: > > > Nice work Marko! > > I had two (not big deal) questions. First, when you > > specify the --cache parameters as you did for SAML, could the cache file > > be omitted? > > > > For example: kcreg --cache -r saml-realm ... > > > > I was thinking that once you specified the realm name, the API will just > > look for ~/.keycloak/saml-realm.cache. It's just an idea > > > We could maybe add this behaviour in addition to current behaviour. It's > not enough to just specify a realm though, since server can also be > different. For example: > > # login as admin user in master realm on localhost using default cache > file (~/.keycloak/kcreg.cache) > kcreg login -s http://localhost:8080/auth -r master -u admin > > # login as admin user in master realm on login.example.com using a > different cache file > kcreg --cache ~/.keycloak/example_com.cache login -s > http://login.example.com -r master -u admin > > > Using kcreg --cache -r master ... as above would default to the same file > (~/.keycloak/master.cache) unless we also include server_endpoint in the > file name e.g.: localhost_8080_auth_master.cache. But then - login command > gets the server specified by user. Not so with other commands. > > The current mechanism reads the server from the specified cache file (the > server for current session it's stored inside a JSON): > > kcreg --cache ~/.keycloak/localhost_8080_auth_master.cache get my_client > > > So your proposal is unable to determine the full name of the file - we need > to know the server already to compose the file name: > > kcreg --cache -r master get my_client > > The above can resolve to ~/.keycloak/master.cache but doesn't have enough > info to resolve to ~/.keycloak/localhost_8080_auth_master.cache. > > If we also have to specify server the result is not worth the bother: > > kcreg --cache -s http://localhost:8080/auth -r master get my_client > > > Another thing - if we want to also support current behavior (which allows > all the freedom and flexibility of choosing any location on the filesystem > for the cache file) we would then need to treat additional argument to > --cache as optional, which can quickly get tricky: > > kcreg --cache login -r master ... > > vs. > > kcreg --cache /tmp/session.cache -x login ... > > vs. > > kcreg --cache -r master get ... > > > We could do that by checking if next argument begins with a '-' but that > would disable usage of any filename starting with '-'. And we would have to > treat it differently for login ... > > The more I look at it, the more complex and tricky it gets to get it right. > > > One quite simple solution towards more ergonomic usage would be to simply > differentiate whether the specified path is absolute or relative, and if > relative we could default the directory to ~/.keycloak. > > For example: > > kcreg --cache master login -s http://localhost:8080/auth -r master -u admin > > This would generate the following cache file: ~/.keycloak/master.cache, and > the folling command would use that file as well: > > kcreg --cache master get my_client > > > The absolute names would be those starting with /, ~/ on unix, c:\, d:\ ... > on Windows > > This behaviour is easy to add. > > > > > > > Second question, is more like something to think if worth to take > > into consideration. Most of the examples that I saw, make use of > > username/password. But if the admin enables two factor authentication, > > she might be unable to use our client-reg CLI, or enforce weaken security > > only > > to make use of the CLI. > > > > Is OTP support planned for further iterations? > > > I don't know how exactly OTP auth works under the hood, but if Stian says > it's no problem and it's easy to implement then that's your answer :) > > > > > > > > On 2016-07-21, Marko Strukelj wrote: > > > And if anyone wants to get their feet wet already: > > > > > > > > https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool > > > > > > > > > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen > > > wrote: > > > > > > > Great work Marko! > > > > > > > > As we didn't have time to go through feedback let's use this thread for > > > > it. Add your questions and comments here please. > > > > > > > > _______________________________________________ > > > > 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 > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > -- abstractj PGP: 0x84DC9914 From mstrukel at redhat.com Fri Jul 22 06:11:35 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 Jul 2016 12:11:35 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: I don't have kcreg.bat yet ... contributions welcome :) Making it part of keycloak server distro makes sense. OTOH I believe we have some developers that just deal with HTML5 web apps who don't have Keycloak Server installed locally. If that was the only way to get kcreg they would have to download the whole server just to get the tool. For them it makes sense to also have a separate CLI Tools download. On Fri, Jul 22, 2016 at 9:40 AM, Stian Thorgersen wrote: > One more: > > * How should we distribute it? I propose we just add kcreg.sh/kcreg.bat + > the JAR to the bin directory of the server > > On 22 July 2016 at 09:33, Stian Thorgersen wrote: > >> A few questions from me: >> >> * Is it possible to view the returned JSON when creating and updating a >> client? This contains values filled in by the server, including the >> registration access token. >> * Should we not enable pretty print by default? >> * --cache isn't the most intuitive name, I don't have a better suggestion >> though >> * Docs should be moved to Gitbook "Securing Clients and Applications >> guide" >> * When creating clients and later updating them I assume it uses the >> registration access token from the cache? >> * A nice addition would be the ability to list attributes from >> ClientRepresentation so it's easy to discover what attributes can be set >> * What about setting/changing complex attributes, how does that look >> like? Can we add/remove to an array? Add/remove elements to a complex >> object? Something like JSON patch could be nice >> https://tools.ietf.org/html/rfc6902 >> >> On 22 July 2016 at 09:26, Stian Thorgersen wrote: >> >>> It should be fairly easy to add support for OTP as well as the direct >>> grant supports that. The user would have to specify to use OTP though. >>> >>> On 21 July 2016 at 19:15, Bruno Oliveira wrote: >>> >>>> Nice work Marko! I had two (not big deal) questions. First, when you >>>> specify the --cache parameters as you did for SAML, could the cache >>>> file be omitted? >>>> >>>> For example: kcreg --cache -r saml-realm ... >>>> >>>> I was thinking that once you specified the realm name, the API will just >>>> look for ~/.keycloak/saml-realm.cache. It's just an idea. >>>> >>>> Second question, is more like something to think if worth to take >>>> into consideration. Most of the examples that I saw, make use of >>>> username/password. But if the admin enables two factor authentication, >>>> she might be unable to use our client-reg CLI, or enforce weaken >>>> security only >>>> to make use of the CLI. >>>> >>>> Is OTP support planned for further iterations? >>>> >>>> >>>> On 2016-07-21, Marko Strukelj wrote: >>>> > And if anyone wants to get their feet wet already: >>>> > >>>> > >>>> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool >>>> > >>>> > >>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen < >>>> sthorger at redhat.com> >>>> > wrote: >>>> > >>>> > > Great work Marko! >>>> > > >>>> > > As we didn't have time to go through feedback let's use this thread >>>> for >>>> > > it. Add your questions and comments here please. >>>> > > >>>> > > _______________________________________________ >>>> > > 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 >>>> >>>> >>>> -- >>>> >>>> abstractj >>>> PGP: 0x84DC9914 >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/268394ad/attachment.html From bruno at abstractj.org Fri Jul 22 06:12:23 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 22 Jul 2016 07:12:23 -0300 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: <20160722101223.GD27222@abstractj.org> On 2016-07-22, Marko Strukelj wrote: > On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen > wrote: > > > A few questions from me: > > > > * Is it possible to view the returned JSON when creating and updating a > > client? This contains values filled in by the server, including the > > registration access token. > > > Not ATM. I can add an option e.g. -o, --output Display the new state > of client configuration. > > > > * Should we not enable pretty print by default? > > > I suppose that would be more user friendly. Just don't know how to name the > switch -p, --pretty is so obvious ... Some command line interfaces use --format. > > > > * --cache isn't the most intuitive name, I don't have a better suggestion > > though > > > OpenShift client uses the term configuration rather than cache, and uses > --config accordingly. We could do the same, and even add 'kcreg config' > command to inspect and edit the config file if we deem that necessary. > > * Docs should be moved to Gitbook "Securing Clients and Applications guide" > > > The only doc currently is the README file, so I guess that's the one you > mean. I'd wait a bit with adding it to docbook. The later I make a copy in > Gitbook the less double work will there be editing the changes. > > > > * When creating clients and later updating them I assume it uses the > > registration access token from the cache? > > > Yes. If it can't find one it uses bearer token from login. > > > > * A nice addition would be the ability to list attributes from > > ClientRepresentation so it's easy to discover what attributes can be set > > > That's trivial to add using reflection. But how would the UI look? Ideally > we'd have tab completion for this at some point. > > Something like this? > > $ kcreg list-attrs > clientId String > redirectUris List > baseUrl String > enabled Boolean > ... > > $ kcreg list-attrs -e oidc > redirect_uris List > grant_types List > > > However if we want to be more specific, with some additional help on the > meaning, and possible values, then we would need to annotate Representation > classes with the necessary info, or simply have a help-style static text. > > > > > * What about setting/changing complex attributes, how does that look like? > > Can we add/remove to an array? Add/remove elements to a complex object? > > Something like JSON patch could be nice > > https://tools.ietf.org/html/rfc6902 > > > I haven't gone so far with this iteration. That's a TODO. > > > > > > On 22 July 2016 at 09:26, Stian Thorgersen wrote: > > > >> It should be fairly easy to add support for OTP as well as the direct > >> grant supports that. The user would have to specify to use OTP though. > >> > >> On 21 July 2016 at 19:15, Bruno Oliveira wrote: > >> > >>> Nice work Marko! I had two (not big deal) questions. First, when you > >>> specify the --cache parameters as you did for SAML, could the cache file > >>> be omitted? > >>> > >>> For example: kcreg --cache -r saml-realm ... > >>> > >>> I was thinking that once you specified the realm name, the API will just > >>> look for ~/.keycloak/saml-realm.cache. It's just an idea. > >>> > >>> Second question, is more like something to think if worth to take > >>> into consideration. Most of the examples that I saw, make use of > >>> username/password. But if the admin enables two factor authentication, > >>> she might be unable to use our client-reg CLI, or enforce weaken > >>> security only > >>> to make use of the CLI. > >>> > >>> Is OTP support planned for further iterations? > >>> > >>> > >>> On 2016-07-21, Marko Strukelj wrote: > >>> > And if anyone wants to get their feet wet already: > >>> > > >>> > > >>> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool > >>> > > >>> > > >>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen >>> > > >>> > wrote: > >>> > > >>> > > Great work Marko! > >>> > > > >>> > > As we didn't have time to go through feedback let's use this thread > >>> for > >>> > > it. Add your questions and comments here please. > >>> > > > >>> > > _______________________________________________ > >>> > > 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 > >>> > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> > >> > >> > > -- abstractj PGP: 0x84DC9914 From mstrukel at redhat.com Fri Jul 22 06:18:01 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 Jul 2016 12:18:01 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: <20160722101223.GD27222@abstractj.org> References: <20160721171509.GA22848@abstractj.org> <20160722101223.GD27222@abstractj.org> Message-ID: That would work: -n, --no-format Much better than -n, --no-pretty :) On Fri, Jul 22, 2016 at 12:12 PM, Bruno Oliveira wrote: > On 2016-07-22, Marko Strukelj wrote: > > On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen > > wrote: > > > > > A few questions from me: > > > > > > * Is it possible to view the returned JSON when creating and updating a > > > client? This contains values filled in by the server, including the > > > registration access token. > > > > > Not ATM. I can add an option e.g. -o, --output Display the new state > > of client configuration. > > > > > > > * Should we not enable pretty print by default? > > > > > I suppose that would be more user friendly. Just don't know how to name > the > > switch -p, --pretty is so obvious ... > > Some command line interfaces use --format. > > > > > > > > * --cache isn't the most intuitive name, I don't have a better > suggestion > > > though > > > > > OpenShift client uses the term configuration rather than cache, and uses > > --config accordingly. We could do the same, and even add 'kcreg config' > > command to inspect and edit the config file if we deem that necessary. > > > > * Docs should be moved to Gitbook "Securing Clients and Applications > guide" > > > > > The only doc currently is the README file, so I guess that's the one you > > mean. I'd wait a bit with adding it to docbook. The later I make a copy > in > > Gitbook the less double work will there be editing the changes. > > > > > > > * When creating clients and later updating them I assume it uses the > > > registration access token from the cache? > > > > > Yes. If it can't find one it uses bearer token from login. > > > > > > > * A nice addition would be the ability to list attributes from > > > ClientRepresentation so it's easy to discover what attributes can be > set > > > > > That's trivial to add using reflection. But how would the UI look? > Ideally > > we'd have tab completion for this at some point. > > > > Something like this? > > > > $ kcreg list-attrs > > clientId String > > redirectUris List > > baseUrl String > > enabled Boolean > > ... > > > > $ kcreg list-attrs -e oidc > > redirect_uris List > > grant_types List > > > > > > However if we want to be more specific, with some additional help on the > > meaning, and possible values, then we would need to annotate > Representation > > classes with the necessary info, or simply have a help-style static text. > > > > > > > > > * What about setting/changing complex attributes, how does that look > like? > > > Can we add/remove to an array? Add/remove elements to a complex object? > > > Something like JSON patch could be nice > > > https://tools.ietf.org/html/rfc6902 > > > > > I haven't gone so far with this iteration. That's a TODO. > > > > > > > > > > On 22 July 2016 at 09:26, Stian Thorgersen > wrote: > > > > > >> It should be fairly easy to add support for OTP as well as the direct > > >> grant supports that. The user would have to specify to use OTP though. > > >> > > >> On 21 July 2016 at 19:15, Bruno Oliveira wrote: > > >> > > >>> Nice work Marko! I had two (not big deal) questions. First, when you > > >>> specify the --cache parameters as you did for SAML, could the cache > file > > >>> be omitted? > > >>> > > >>> For example: kcreg --cache -r saml-realm ... > > >>> > > >>> I was thinking that once you specified the realm name, the API will > just > > >>> look for ~/.keycloak/saml-realm.cache. It's just an idea. > > >>> > > >>> Second question, is more like something to think if worth to take > > >>> into consideration. Most of the examples that I saw, make use of > > >>> username/password. But if the admin enables two factor > authentication, > > >>> she might be unable to use our client-reg CLI, or enforce weaken > > >>> security only > > >>> to make use of the CLI. > > >>> > > >>> Is OTP support planned for further iterations? > > >>> > > >>> > > >>> On 2016-07-21, Marko Strukelj wrote: > > >>> > And if anyone wants to get their feet wet already: > > >>> > > > >>> > > > >>> > https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool > > >>> > > > >>> > > > >>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen < > sthorger at redhat.com > > >>> > > > >>> > wrote: > > >>> > > > >>> > > Great work Marko! > > >>> > > > > >>> > > As we didn't have time to go through feedback let's use this > thread > > >>> for > > >>> > > it. Add your questions and comments here please. > > >>> > > > > >>> > > _______________________________________________ > > >>> > > 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 > > >>> > > >>> > > >>> -- > > >>> > > >>> abstractj > > >>> PGP: 0x84DC9914 > > >>> > > >> > > >> > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/809f7872/attachment-0001.html From sthorger at redhat.com Fri Jul 22 06:20:49 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 22 Jul 2016 12:20:49 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: On 22 July 2016 at 12:02, Marko Strukelj wrote: > > > On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen > wrote: > >> A few questions from me: >> >> * Is it possible to view the returned JSON when creating and updating a >> client? This contains values filled in by the server, including the >> registration access token. >> > Not ATM. I can add an option e.g. -o, --output Display the new state > of client configuration. > Please do > > >> * Should we not enable pretty print by default? >> > I suppose that would be more user friendly. Just don't know how to name > the switch -p, --pretty is so obvious ... > -u --ugly ;) or a more serious suggestion -c --compressed > > >> * --cache isn't the most intuitive name, I don't have a better suggestion >> though >> > OpenShift client uses the term configuration rather than cache, and uses > --config accordingly. We could do the same, and even add 'kcreg config' > command to inspect and edit the config file if we deem that necessary. > +1 --config is better - config would be nice as well > > * Docs should be moved to Gitbook "Securing Clients and Applications guide" >> > The only doc currently is the README file, so I guess that's the one you > mean. I'd wait a bit with adding it to docbook. The later I make a copy in > Gitbook the less double work will there be editing the changes. > Sure, just remember to do it before moving on to Admin CLI > > >> * When creating clients and later updating them I assume it uses the >> registration access token from the cache? >> > Yes. If it can't find one it uses bearer token from login. > > >> * A nice addition would be the ability to list attributes from >> ClientRepresentation so it's easy to discover what attributes can be set >> > That's trivial to add using reflection. But how would the UI look? Ideally > we'd have tab completion for this at some point. > > Something like this? > > $ kcreg list-attrs > clientId String > redirectUris List > baseUrl String > enabled Boolean > ... > > $ kcreg list-attrs -e oidc > redirect_uris List > grant_types List > That's fine and you only need it for our representation. I wouldn't use Java names for types though, rather use JSON names > > > However if we want to be more specific, with some additional help on the > meaning, and possible values, then we would need to annotate Representation > classes with the necessary info, or simply have a help-style static text. > > > >> * What about setting/changing complex attributes, how does that look >> like? Can we add/remove to an array? Add/remove elements to a complex >> object? Something like JSON patch could be nice >> https://tools.ietf.org/html/rfc6902 >> > I haven't gone so far with this iteration. That's a TODO. > Ok, would nice to visit before we start on Admin CLI as it would be incredibly useful there. > > >> >> On 22 July 2016 at 09:26, Stian Thorgersen wrote: >> >>> It should be fairly easy to add support for OTP as well as the direct >>> grant supports that. The user would have to specify to use OTP though. >>> >>> On 21 July 2016 at 19:15, Bruno Oliveira wrote: >>> >>>> Nice work Marko! I had two (not big deal) questions. First, when you >>>> specify the --cache parameters as you did for SAML, could the cache >>>> file be omitted? >>>> >>>> For example: kcreg --cache -r saml-realm ... >>>> >>>> I was thinking that once you specified the realm name, the API will just >>>> look for ~/.keycloak/saml-realm.cache. It's just an idea. >>>> >>>> Second question, is more like something to think if worth to take >>>> into consideration. Most of the examples that I saw, make use of >>>> username/password. But if the admin enables two factor authentication, >>>> she might be unable to use our client-reg CLI, or enforce weaken >>>> security only >>>> to make use of the CLI. >>>> >>>> Is OTP support planned for further iterations? >>>> >>>> >>>> On 2016-07-21, Marko Strukelj wrote: >>>> > And if anyone wants to get their feet wet already: >>>> > >>>> > >>>> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool >>>> > >>>> > >>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen < >>>> sthorger at redhat.com> >>>> > wrote: >>>> > >>>> > > Great work Marko! >>>> > > >>>> > > As we didn't have time to go through feedback let's use this thread >>>> for >>>> > > it. Add your questions and comments here please. >>>> > > >>>> > > _______________________________________________ >>>> > > 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 >>>> >>>> >>>> -- >>>> >>>> abstractj >>>> PGP: 0x84DC9914 >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/040fe057/attachment.html From sthorger at redhat.com Fri Jul 22 06:22:13 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 22 Jul 2016 12:22:13 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: Ok, so let's do both then - included with server + separate download. One download for both cli reg and admin cli is probably sufficient right? On 22 July 2016 at 12:11, Marko Strukelj wrote: > I don't have kcreg.bat yet ... contributions welcome :) > > Making it part of keycloak server distro makes sense. OTOH I believe we > have some developers that just deal with HTML5 web apps who don't have > Keycloak Server installed locally. If that was the only way to get kcreg > they would have to download the whole server just to get the tool. For them > it makes sense to also have a separate CLI Tools download. > > > On Fri, Jul 22, 2016 at 9:40 AM, Stian Thorgersen > wrote: > >> One more: >> >> * How should we distribute it? I propose we just add kcreg.sh/kcreg.bat >> + the JAR to the bin directory of the server >> >> On 22 July 2016 at 09:33, Stian Thorgersen wrote: >> >>> A few questions from me: >>> >>> * Is it possible to view the returned JSON when creating and updating a >>> client? This contains values filled in by the server, including the >>> registration access token. >>> * Should we not enable pretty print by default? >>> * --cache isn't the most intuitive name, I don't have a better >>> suggestion though >>> * Docs should be moved to Gitbook "Securing Clients and Applications >>> guide" >>> * When creating clients and later updating them I assume it uses the >>> registration access token from the cache? >>> * A nice addition would be the ability to list attributes from >>> ClientRepresentation so it's easy to discover what attributes can be set >>> * What about setting/changing complex attributes, how does that look >>> like? Can we add/remove to an array? Add/remove elements to a complex >>> object? Something like JSON patch could be nice >>> https://tools.ietf.org/html/rfc6902 >>> >>> On 22 July 2016 at 09:26, Stian Thorgersen wrote: >>> >>>> It should be fairly easy to add support for OTP as well as the direct >>>> grant supports that. The user would have to specify to use OTP though. >>>> >>>> On 21 July 2016 at 19:15, Bruno Oliveira wrote: >>>> >>>>> Nice work Marko! I had two (not big deal) questions. First, when you >>>>> specify the --cache parameters as you did for SAML, could the cache >>>>> file be omitted? >>>>> >>>>> For example: kcreg --cache -r saml-realm ... >>>>> >>>>> I was thinking that once you specified the realm name, the API will >>>>> just >>>>> look for ~/.keycloak/saml-realm.cache. It's just an idea. >>>>> >>>>> Second question, is more like something to think if worth to take >>>>> into consideration. Most of the examples that I saw, make use of >>>>> username/password. But if the admin enables two factor authentication, >>>>> she might be unable to use our client-reg CLI, or enforce weaken >>>>> security only >>>>> to make use of the CLI. >>>>> >>>>> Is OTP support planned for further iterations? >>>>> >>>>> >>>>> On 2016-07-21, Marko Strukelj wrote: >>>>> > And if anyone wants to get their feet wet already: >>>>> > >>>>> > >>>>> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool >>>>> > >>>>> > >>>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen < >>>>> sthorger at redhat.com> >>>>> > wrote: >>>>> > >>>>> > > Great work Marko! >>>>> > > >>>>> > > As we didn't have time to go through feedback let's use this >>>>> thread for >>>>> > > it. Add your questions and comments here please. >>>>> > > >>>>> > > _______________________________________________ >>>>> > > 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 >>>>> >>>>> >>>>> -- >>>>> >>>>> abstractj >>>>> PGP: 0x84DC9914 >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/01c597d5/attachment-0001.html From mstrukel at redhat.com Fri Jul 22 06:34:51 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 Jul 2016 12:34:51 +0200 Subject: [keycloak-dev] Feedback on Client Registration CLI In-Reply-To: References: <20160721171509.GA22848@abstractj.org> Message-ID: +1 On Fri, Jul 22, 2016 at 12:22 PM, Stian Thorgersen wrote: > Ok, so let's do both then - included with server + separate download. One > download for both cli reg and admin cli is probably sufficient right? > > On 22 July 2016 at 12:11, Marko Strukelj wrote: > >> I don't have kcreg.bat yet ... contributions welcome :) >> >> Making it part of keycloak server distro makes sense. OTOH I believe we >> have some developers that just deal with HTML5 web apps who don't have >> Keycloak Server installed locally. If that was the only way to get kcreg >> they would have to download the whole server just to get the tool. For them >> it makes sense to also have a separate CLI Tools download. >> >> >> On Fri, Jul 22, 2016 at 9:40 AM, Stian Thorgersen >> wrote: >> >>> One more: >>> >>> * How should we distribute it? I propose we just add kcreg.sh/kcreg.bat >>> + the JAR to the bin directory of the server >>> >>> On 22 July 2016 at 09:33, Stian Thorgersen wrote: >>> >>>> A few questions from me: >>>> >>>> * Is it possible to view the returned JSON when creating and updating a >>>> client? This contains values filled in by the server, including the >>>> registration access token. >>>> * Should we not enable pretty print by default? >>>> * --cache isn't the most intuitive name, I don't have a better >>>> suggestion though >>>> * Docs should be moved to Gitbook "Securing Clients and Applications >>>> guide" >>>> * When creating clients and later updating them I assume it uses the >>>> registration access token from the cache? >>>> * A nice addition would be the ability to list attributes from >>>> ClientRepresentation so it's easy to discover what attributes can be set >>>> * What about setting/changing complex attributes, how does that look >>>> like? Can we add/remove to an array? Add/remove elements to a complex >>>> object? Something like JSON patch could be nice >>>> https://tools.ietf.org/html/rfc6902 >>>> >>>> On 22 July 2016 at 09:26, Stian Thorgersen wrote: >>>> >>>>> It should be fairly easy to add support for OTP as well as the direct >>>>> grant supports that. The user would have to specify to use OTP though. >>>>> >>>>> On 21 July 2016 at 19:15, Bruno Oliveira wrote: >>>>> >>>>>> Nice work Marko! I had two (not big deal) questions. First, when you >>>>>> specify the --cache parameters as you did for SAML, could the cache >>>>>> file be omitted? >>>>>> >>>>>> For example: kcreg --cache -r saml-realm ... >>>>>> >>>>>> I was thinking that once you specified the realm name, the API will >>>>>> just >>>>>> look for ~/.keycloak/saml-realm.cache. It's just an idea. >>>>>> >>>>>> Second question, is more like something to think if worth to take >>>>>> into consideration. Most of the examples that I saw, make use of >>>>>> username/password. But if the admin enables two factor authentication, >>>>>> she might be unable to use our client-reg CLI, or enforce weaken >>>>>> security only >>>>>> to make use of the CLI. >>>>>> >>>>>> Is OTP support planned for further iterations? >>>>>> >>>>>> >>>>>> On 2016-07-21, Marko Strukelj wrote: >>>>>> > And if anyone wants to get their feet wet already: >>>>>> > >>>>>> > >>>>>> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool >>>>>> > >>>>>> > >>>>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen < >>>>>> sthorger at redhat.com> >>>>>> > wrote: >>>>>> > >>>>>> > > Great work Marko! >>>>>> > > >>>>>> > > As we didn't have time to go through feedback let's use this >>>>>> thread for >>>>>> > > it. Add your questions and comments here please. >>>>>> > > >>>>>> > > _______________________________________________ >>>>>> > > 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 >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> abstractj >>>>>> PGP: 0x84DC9914 >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/981f0213/attachment.html From mposolda at redhat.com Fri Jul 22 12:50:06 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 22 Jul 2016 18:50:06 +0200 Subject: [keycloak-dev] Keycloak Version 2.0.0 : MongoDB Start-up Issue. In-Reply-To: <3DE4BF1BF8EDD84B8F8D61B0A88BD563101C5D@EXCH01.gandlake.local> References: <3DE4BF1BF8EDD84B8F8D61B0A88BD563101C5D@EXCH01.gandlake.local> Message-ID: <57924EBE.1080303@redhat.com> It seems the docs is not up-to-date. Created JIRA https://issues.jboss.org/browse/KEYCLOAK-3357 and will be fixed in next version. You also need to replace: "userSessionPersister": { "provider": "jpa" }, "authorizationPersister": { "provider": "jpa" }, providers with "mongo" Marek On 22/07/16 10:56, Stephen Merchant wrote: > > Hello, > > I am assessing standalone Keycloak version *2.0.0* configured for > MongoDB Version *3.2.8* persistence. > > I have made configuration changes to > /?\standalone\configuration\keycloak-server.json/ as advised here > . > > On start-up : > > 1)I can see the *keycloak* database get created in my MongoDB instance. > > 2)On standalone Keycloak startup I get the exception detailed in the > WildFly log snippet below. > > I would appreciate any advice or assistance you have to offer with > this issue. > > Thank you. > > 09:41:00,981 INFO [org.mongodb.driver.connection] (ServerService > Thread Pool -- 47) *Opened connection*[connectionId{localValue:2, > serverValue:14}] to localhost:27017 > > 09:41:01,625 WARN > [org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory] > (ServerService Thread Pool -- 47) Can't rollback connection: > java.sql.SQLException: IJ031022: You cannot rollback with autocommit set > > at > org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.jdbcRollback(BaseWrapperManagedConnection.java:1124) > > at > org.jboss.jca.adapters.jdbc.WrappedConnection.rollback(WrappedConnection.java:863) > > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:196) > > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:60) > > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:48) > > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) > > at > org.keycloak.models.jpa.session.JpaUserSessionPersisterProviderFactory.create(JpaUserSessionPersisterProviderFactory.java:38) > > at > org.keycloak.models.jpa.session.JpaUserSessionPersisterProviderFactory.create(JpaUserSessionPersisterProviderFactory.java:32) > > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) > > at > org.keycloak.models.sessions.infinispan.initializer.OfflineUserSessionLoader.init(OfflineUserSessionLoader.java:38) > > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer$1.run(InfinispanUserSessionInitializer.java:110) > > at > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) > > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.getOrCreateInitializerState(InfinispanUserSessionInitializer.java:107) > > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.startLoading(InfinispanUserSessionInitializer.java:158) > > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.loadPersistentSessions(InfinispanUserSessionInitializer.java:88) > > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$2.run(InfinispanUserSessionProviderFactory.java:91) > > at > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) > > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory.loadPersistentSessions(InfinispanUserSessionProviderFactory.java:82) > > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$1.onEvent(InfinispanUserSessionProviderFactory.java:71) > > at > org.keycloak.services.DefaultKeycloakSessionFactory.publish(DefaultKeycloakSessionFactory.java:64) > > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:130) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) > > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) > > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) > > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) > > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) > > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) > > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) > > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > at java.lang.Thread.run(Thread.java:745) > > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > > 09:41:01,670 ERROR [org.jboss.msc.service.fail] (ServerService Thread > Pool -- 47) MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./auth: > org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: RESTEASY003325: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) > > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > at java.lang.Thread.run(Thread.java:745) > > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > > Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to > construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) > > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) > > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) > > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) > > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) > > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) > > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) > > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > > ... 6 more > > Caused by: java.lang.IllegalStateException: Trying to update database, > but don't have a DB lock acquired > > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:165) > > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:60) > > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:48) > > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) > > at > org.keycloak.models.jpa.session.JpaUserSessionPersisterProviderFactory.create(JpaUserSessionPersisterProviderFactory.java:38) > > at > org.keycloak.models.jpa.session.JpaUserSessionPersisterProviderFactory.create(JpaUserSessionPersisterProviderFactory.java:32) > > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) > > at > org.keycloak.models.sessions.infinispan.initializer.OfflineUserSessionLoader.init(OfflineUserSessionLoader.java:38) > > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer$1.run(InfinispanUserSessionInitializer.java:110) > > at > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) > > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.getOrCreateInitializerState(InfinispanUserSessionInitializer.java:107) > > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.startLoading(InfinispanUserSessionInitializer.java:158) > > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.loadPersistentSessions(InfinispanUserSessionInitializer.java:88) > > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$2.run(InfinispanUserSessionProviderFactory.java:91) > > at > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:287) > > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory.loadPersistentSessions(InfinispanUserSessionProviderFactory.java:82) > > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$1.onEvent(InfinispanUserSessionProviderFactory.java:71) > > at > org.keycloak.services.DefaultKeycloakSessionFactory.publish(DefaultKeycloakSessionFactory.java:64) > > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:130) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) > > ... 19 more > > 09:41:01,730 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - > address: ([("deployment" => "keycloak-server.war")]) - failure > description: {"WFLYCTL0080: Failed services" => > {"jboss.undertow.deployment.default-server.default-host./auth" => > "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: RESTEASY003325: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to > construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > Caused by: java.lang.IllegalStateException: Trying to update > database, but don't have a DB lock acquired"}} > > 09:41:01,775 INFO [org.jboss.as.server] (ServerService Thread Pool -- > 44) WFLYSRV0010: Deployed "keycloak-server.war" (runtime-name : > "keycloak-server.war") > > 09:41:01,779 INFO [org.jboss.as.controller] (Controller Boot Thread) > WFLYCTL0183: Service status report > > WFLYCTL0186: Services which failed to start: service > jboss.undertow.deployment.default-server.default-host./auth: > org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: RESTEASY003325: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > 09:41:01,997 INFO [org.jboss.as] (Controller Boot Thread) > WFLYSRV0060: Http management interface listening on > http://127.0.0.1:9990/management > > 09:41:02,012 INFO [org.jboss.as] (Controller Boot Thread) > WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > > 09:41:02,013 ERROR [org.jboss.as] (Controller Boot Thread) > WFLYSRV0026: Keycloak 2.0.0.Final (WildFly Core 2.0.10.Final) started > (with errors) in 7942ms - Started 414 of 799 services (2 services > failed or missing dependencies, 542 services are lazy, passive or > on-demand) > > Stephen Merchant > > Developer > > Gandlake Limited > > Crown Commercial Service Supplier > BSI ISO/IEC 27001 certification number IS 585161 > > > Gandlake Limited, a Limited Liability Company registered in England > and Wales under number 4667925. Registered Office: Gandlake House, > London Road, Newbury, Berkshire. RG14 1LA. VAT Registration Number 809 > 7164 11 > > > _______________________________________________ > 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/20160722/9a03a44b/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 11984 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/9a03a44b/attachment-0001.png From mposolda at redhat.com Fri Jul 22 12:57:45 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 22 Jul 2016 18:57:45 +0200 Subject: [keycloak-dev] Read-only attributes for UserFederation providers In-Reply-To: <20160722095124.GB27222@abstractj.org> References: <20160722095124.GB27222@abstractj.org> Message-ID: <57925089.7050606@redhat.com> +1 Marek On 22/07/16 11:51, Bruno Oliveira wrote: > Good morning, > > I was working on this issue[1] this week and thinking about how > to tell our interface that the federation provider has read-only > attributes. > > For example, today for the LDAPFederationProvider[2], we > provide server side validations telling our user that they cannot edit > those attributes. But still, input fields are editable and user > will only know after hit the submit button. > > Not sure if makes sense, but very maybe if we provide a method > at UserFederation like: > > boolean isReadOnly(); //defaults to false or override it and return true > > And later expose it to the interface, we could bring the > text field properties set to read-only. > > Does it make any sense? > > > [1] - https://issues.jboss.org/browse/KEYCLOAK-3060 > [2] - https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/federation/ldap/src/main/java/org/keycloak/federation/ldap/ReadonlyLDAPUserModelDelegate.java#L38-L64 > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From jdennis at redhat.com Sat Jul 23 09:15:01 2016 From: jdennis at redhat.com (John Dennis) Date: Sat, 23 Jul 2016 09:15:01 -0400 Subject: [keycloak-dev] map Red Hat Single Sign-On version to git tag Message-ID: I've got "Red Hat Single Sign-On - Version 7.0.0.GA" installed and I need to see the source code matching that version. Normally I would look at the git tags to find a release but there doesn't seem to be a tag related to this release. How do I map what is in version.txt to a git tag? Is there a document somewhere? What is the matching tag for "Red Hat Single Sign-On - Version 7.0.0.GA" -- John From bburke at redhat.com Mon Jul 25 10:59:17 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 25 Jul 2016 10:59:17 -0400 Subject: [keycloak-dev] changes to KeycloakTransaction and KeycloakTransactionManager API Message-ID: <304a9314-cee9-0c20-8cf2-c0016c63e2ba@redhat.com> I want to simplify KeycloakTransaction interface a bit and remove the getRolbackOnly, setRollbackOnly, and isActive and only have them within KeycloakTransationManager. I may have to refactor existing components to handle this. See any issues? All this is the continuous process of simplying our SPIs to make them easier to implement. Bill From bruno at abstractj.org Mon Jul 25 11:03:12 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 25 Jul 2016 12:03:12 -0300 Subject: [keycloak-dev] changes to KeycloakTransaction and KeycloakTransactionManager API In-Reply-To: <304a9314-cee9-0c20-8cf2-c0016c63e2ba@redhat.com> References: <304a9314-cee9-0c20-8cf2-c0016c63e2ba@redhat.com> Message-ID: <20160725150312.GA19631@abstractj.org> +1 On 2016-07-25, Bill Burke wrote: > I want to simplify KeycloakTransaction interface a bit and remove the > getRolbackOnly, setRollbackOnly, and isActive and only have them within > KeycloakTransationManager. I may have to refactor existing components > to handle this. See any issues? All this is the continuous process of > simplying our SPIs to make them easier to implement. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Mon Jul 25 11:15:42 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 25 Jul 2016 12:15:42 -0300 Subject: [keycloak-dev] map Red Hat Single Sign-On version to git tag In-Reply-To: References: Message-ID: <20160725151542.GB19631@abstractj.org> Hi John, I believe that this is what you're looking for https://access.redhat.com/articles/2342881. I hope it helps. On 2016-07-23, John Dennis wrote: > I've got "Red Hat Single Sign-On - Version 7.0.0.GA" installed and I > need to see the source code matching that version. Normally I would look > at the git tags to find a release but there doesn't seem to be a tag > related to this release. > > How do I map what is in version.txt to a git tag? Is there a document > somewhere? > > What is the matching tag for "Red Hat Single Sign-On - Version 7.0.0.GA" > > -- > John > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Mon Jul 25 11:29:08 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 25 Jul 2016 11:29:08 -0400 Subject: [keycloak-dev] renaming transaction interfaces Message-ID: I am also renaming KeycloakTransaction to KeycloakTransactionSynchronization and KeycloakTransactionManager to KeycloakTransaction. From jdennis at redhat.com Mon Jul 25 11:40:48 2016 From: jdennis at redhat.com (John Dennis) Date: Mon, 25 Jul 2016 11:40:48 -0400 Subject: [keycloak-dev] map Red Hat Single Sign-On version to git tag In-Reply-To: <20160725151542.GB19631@abstractj.org> References: <20160725151542.GB19631@abstractj.org> Message-ID: <7b28dfde-242c-7e89-1085-71c73c4456d3@redhat.com> On 07/25/2016 11:15 AM, Bruno Oliveira wrote: > Hi John, I believe that this is what you're looking for https://access.redhat.com/articles/2342881. > > I hope it helps. Thank you Bruno! That is exactly what I was looking for. > On 2016-07-23, John Dennis wrote: >> I've got "Red Hat Single Sign-On - Version 7.0.0.GA" installed and I >> need to see the source code matching that version. Normally I would look >> at the git tags to find a release but there doesn't seem to be a tag >> related to this release. >> >> How do I map what is in version.txt to a git tag? Is there a document >> somewhere? >> >> What is the matching tag for "Red Hat Single Sign-On - Version 7.0.0.GA" -- John From jdennis at redhat.com Mon Jul 25 14:45:43 2016 From: jdennis at redhat.com (John Dennis) Date: Mon, 25 Jul 2016 14:45:43 -0400 Subject: [keycloak-dev] map Red Hat Single Sign-On version to git tag In-Reply-To: <20160725151542.GB19631@abstractj.org> References: <20160725151542.GB19631@abstractj.org> Message-ID: <2fec7673-baff-c8a6-c28a-642610c01ee5@redhat.com> On 07/25/2016 11:15 AM, Bruno Oliveira wrote: > Hi John, I believe that this is what you're looking for https://access.redhat.com/articles/2342881. > > I hope it helps. Hmm ... something seems amiss, the page you reference above says Red Hat Single Sign-0n is based on Keycloak 1.9.8 but there is no git tag for 1.9.8. The tag sequence is: ... 1.9.7.Final 2.0.0.CR1 ... So is the web page wrong and it's based in 1.9.7.Final or was 1.9.8 never tagged for some reason? > On 2016-07-23, John Dennis wrote: >> I've got "Red Hat Single Sign-On - Version 7.0.0.GA" installed and I >> need to see the source code matching that version. Normally I would look >> at the git tags to find a release but there doesn't seem to be a tag >> related to this release. >> >> How do I map what is in version.txt to a git tag? Is there a document >> somewhere? >> >> What is the matching tag for "Red Hat Single Sign-On - Version 7.0.0.GA" >> >> -- >> John >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > > abstractj > PGP: 0x84DC9914 > -- John From bruno at abstractj.org Mon Jul 25 15:00:20 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 25 Jul 2016 16:00:20 -0300 Subject: [keycloak-dev] map Red Hat Single Sign-On version to git tag In-Reply-To: <2fec7673-baff-c8a6-c28a-642610c01ee5@redhat.com> References: <20160725151542.GB19631@abstractj.org> <2fec7673-baff-c8a6-c28a-642610c01ee5@redhat.com> Message-ID: <20160725190020.GA7335@abstractj.org> The tag is there https://github.com/keycloak/keycloak/tree/1.9.8.Final On 2016-07-25, John Dennis wrote: > On 07/25/2016 11:15 AM, Bruno Oliveira wrote: > > Hi John, I believe that this is what you're looking for https://access.redhat.com/articles/2342881. > > > > I hope it helps. > > Hmm ... something seems amiss, the page you reference above says Red Hat > Single Sign-0n is based on Keycloak 1.9.8 but there is no git tag for 1.9.8. > The tag sequence is: > > ... 1.9.7.Final 2.0.0.CR1 ... > > So is the web page wrong and it's based in 1.9.7.Final or was 1.9.8 never > tagged for some reason? > > > > On 2016-07-23, John Dennis wrote: > > > I've got "Red Hat Single Sign-On - Version 7.0.0.GA" installed and I > > > need to see the source code matching that version. Normally I would look > > > at the git tags to find a release but there doesn't seem to be a tag > > > related to this release. > > > > > > How do I map what is in version.txt to a git tag? Is there a document > > > somewhere? > > > > > > What is the matching tag for "Red Hat Single Sign-On - Version 7.0.0.GA" > > > > > > -- > > > John > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > > > > -- > John -- abstractj PGP: 0x84DC9914 From jdennis at redhat.com Mon Jul 25 15:38:18 2016 From: jdennis at redhat.com (John Dennis) Date: Mon, 25 Jul 2016 15:38:18 -0400 Subject: [keycloak-dev] map Red Hat Single Sign-On version to git tag In-Reply-To: <20160725190020.GA7335@abstractj.org> References: <20160725151542.GB19631@abstractj.org> <2fec7673-baff-c8a6-c28a-642610c01ee5@redhat.com> <20160725190020.GA7335@abstractj.org> Message-ID: On 07/25/2016 03:00 PM, Bruno Oliveira wrote: > The tag is there https://github.com/keycloak/keycloak/tree/1.9.8.Final My bad, I keep forgetting git fetch & pull do not update the set of known tags, you have to perform 2 explicit steps (e.g. git fetch --tags and git fetch) I never did understand why git works this way. After doing a git fetch --tags I can now see the tag. -- John From bruno at abstractj.org Mon Jul 25 17:33:19 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 25 Jul 2016 18:33:19 -0300 Subject: [keycloak-dev] PAM Conversations - Custom login form In-Reply-To: References: <20160718224830.GA4459@abstractj.org> <20160719090035.GB4459@abstractj.org> <20160720140607.GA24947@abstractj.org> Message-ID: <20160725213319.GA21003@abstractj.org> Hi Bill, After giving these ideas a try, I started to think about the FreeIPA flow and how 2FA validation works. If we provide for the first factor username + password or username + (password and OTP - in the same field), credentials will be validated anyways. I was misguided by the second prompt from sudo, thinking that second factor was mandatory (sorry about that). The same happens for the FreeIPA web interface, we just provide username + password and OTP (if it was configured). That said, I believe we don't have to add any extra code, aside of what we already have for the SSSD Federation provider. I've already tested it with and without OTP. The only downside of this approach is the fact that we're not going to have an OTP screen and it has to be documented in some place. Does anyone have objections about leaving the flow as is? On 2016-07-20, Bill Burke wrote: > Just create a different form and new Authenticator. I don't think we want > all this logic with Freemarker, do we? The UI is decoupled from credential > validation on purpose so that you can move things around, i.e. a Username > screen, then the next screen is password/OTP input. > > Another thing you could do is collect credentials and store them in the > ClientSessionModel, then once you've collected the credentials, validate > them all in one go. > > On 7/20/16 10:06 AM, Bruno Oliveira wrote: > > On 2016-07-19, Stian Thorgersen wrote: > > > Adding Bill.. > > > > > > It would probably still be better to use user federation for verifying > > > credentials, but we would need some logic on how to determine what > > > mechanism to use for primary authentication and secondary authentication. > > > Bill was talking about adding some conditional flows to the authentication > > > maybe that's what we need. > > > > > > For now I'd focus on OTP though and then move on to smartcard afterwards. > > I can give it a try and workaround, but I'm not sure if worth the > > effort, assuming that later will be necessary to revisit. > > > > If we hardcode/workaround it on Keycloak, user's coming from FreeIPA > > may have their login denied. Even if we ignore smartcards for now. Why? > > > > Depending on the auth types SSSD will show different login prompts. For > > example: > > > > * Password > > Login prompt - $ Password: > > > > * OTP > > Login prompt -> $ First factor: > > $ Second factor: > > Note: Please notice that they are not validated separately > > > > * Password + OTP -> $ First factor or password: > > > > That's the reason why I would like to make the our login screen > > dynamic. > > > > > On 19 July 2016 at 11:00, Bruno Oliveira wrote: > > > > > > > The problem here is the fact that not necessarily the > > > > first factor will be a pasword or the second factor an OTP. It > > > > could be a smartcard for example. That's why I think is a better idea to > > > > make it dynamic, because we don't have control over it to tell > > > > if the second factor will be a smartcard or an OTP for example. > > > > > > > > Does it make sense? > > > > > > > > On 2016-07-19, Stian Thorgersen wrote: > > > > > Looks like it's better to keep as is and have user federation provider > > > > > validate otp credentials as well. The current OTP authenticator delegates > > > > > to user federation provider, so you'd end up with a separate OTP > > > > > authenticator to do it with PAM. > > > > > > > > > > On 19 July 2016 at 00:48, Bruno Oliveira wrote: > > > > > > > > > > > Good morning, > > > > > > > > > > > > > > > > > > Today to authentication against PAM with just simple username/password > > > > I > > > > > > implemented UserFederationProvider and added the proper PAM login to > > > > > > validCredentials[1]. This covers the most basic scenario. > > > > > > > > > > > > Now I would like to cover a more complex scenario like OTP and change > > > > > > the flow a little bit like this: > > > > > > > > > > > > 1. User providers her username > > > > > > 2. The next screen asks to provide how many factor our user has(For > > > > > > example: OTP, password). We just don't know, PAM will tell what's next. > > > > > > 3. We authenticate against it > > > > > > > > > > > > To see in practice against FreeIPA server, I just recorded it > > > > > > for a practical example[2]. > > > > > > > > > > > > What would be the best approach to implement this flow? I was > > > > considering > > > > > > to > > > > > > move my authentication logic out of SSSD federation provider and > > > > create a > > > > > > PAM > > > > > > authenticator. > > > > > > > > > > > > Does it make sense? > > > > > > > > > > > > [1] - > > > > > > > > > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- > > > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > abstractj > > > > > > PGP: 0x84DC9914 > > > > > > _______________________________________________ > > > > > > keycloak-dev mailing list > > > > > > keycloak-dev at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > -- > > > > > > > > abstractj > > > > PGP: 0x84DC9914 > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > -- abstractj PGP: 0x84DC9914 From psilva at redhat.com Mon Jul 25 20:22:50 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 25 Jul 2016 20:22:50 -0400 (EDT) Subject: [keycloak-dev] clientRole property to Role representation In-Reply-To: <473554518.19409988.1469492465951.JavaMail.zimbra@redhat.com> Message-ID: <2091993831.19410065.1469492570137.JavaMail.zimbra@redhat.com> Hi, Do you see any problem if we add a "clientRole" property to RoleRepresentation ? Regards. Pedro Igor From joakim.lofgren at gmail.com Tue Jul 26 03:30:17 2016 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Tue, 26 Jul 2016 07:30:17 +0000 Subject: [keycloak-dev] Brute force lock out and password reset error Message-ID: Hey, I noticed that if you get your account temporarily locked due to the brute force detection then you cannot reset your password until the temporary locked has been lifted. Is this behaviour intended ? We've gotten a few users that become confused when they do not receive a reset password email, and thus contact us asking for help. Sincerely, Joakim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160726/2e654091/attachment.html From bruno at abstractj.org Tue Jul 26 07:34:53 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 26 Jul 2016 08:34:53 -0300 Subject: [keycloak-dev] Brute force lock out and password reset error In-Reply-To: References: Message-ID: <20160726113453.GC29719@abstractj.org> On 2016-07-26, Joakim L?fgren wrote: > Hey, > > I noticed that if you get your account temporarily locked due to the brute > force detection then you cannot reset your password until the temporary > locked has been lifted. > > Is this behaviour intended ? >From what I can tell, this is how it works today and that's intentional. I think that in order to enable password reset for blocked accounts, rate limiting for password reset should be introduced, otherwise, an attacker could try it again. > > We've gotten a few users that become confused when they do not receive a > reset password email, and thus contact us asking for help. > > > Sincerely, > Joakim > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From joakim.lofgren at gmail.com Wed Jul 27 08:00:14 2016 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Wed, 27 Jul 2016 12:00:14 +0000 Subject: [keycloak-dev] Brute force lock out and password reset error In-Reply-To: <20160726113453.GC29719@abstractj.org> References: <20160726113453.GC29719@abstractj.org> Message-ID: Not if you have to click the link in the email for it to be unlocked ? On Tue, Jul 26, 2016, 13:34 Bruno Oliveira wrote: > On 2016-07-26, Joakim L?fgren wrote: > > Hey, > > > > I noticed that if you get your account temporarily locked due to the > brute > > force detection then you cannot reset your password until the temporary > > locked has been lifted. > > > > Is this behaviour intended ? > > From what I can tell, this is how it works today and that's intentional. > I think that in order to enable password reset for blocked accounts, > rate limiting for password reset should be introduced, otherwise, an > attacker could try it again. > > > > > We've gotten a few users that become confused when they do not receive a > > reset password email, and thus contact us asking for help. > > > > > > Sincerely, > > Joakim > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160727/173efa2e/attachment.html From bruno at abstractj.org Wed Jul 27 08:16:55 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 27 Jul 2016 09:16:55 -0300 Subject: [keycloak-dev] Brute force lock out and password reset error In-Reply-To: References: <20160726113453.GC29719@abstractj.org> Message-ID: <20160727121655.GA22977@abstractj.org> On 2016-07-27, Joakim L?fgren wrote: > Not if you have to click the link in the email for it to be unlocked ? You know that can be easily automated, right? > > On Tue, Jul 26, 2016, 13:34 Bruno Oliveira wrote: > > > On 2016-07-26, Joakim L?fgren wrote: > > > Hey, > > > > > > I noticed that if you get your account temporarily locked due to the > > brute > > > force detection then you cannot reset your password until the temporary > > > locked has been lifted. > > > > > > Is this behaviour intended ? > > > > From what I can tell, this is how it works today and that's intentional. > > I think that in order to enable password reset for blocked accounts, > > rate limiting for password reset should be introduced, otherwise, an > > attacker could try it again. > > > > > > > > We've gotten a few users that become confused when they do not receive a > > > reset password email, and thus contact us asking for help. > > > > > > > > > Sincerely, > > > Joakim > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Wed Jul 27 16:51:57 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 27 Jul 2016 16:51:57 -0400 Subject: [keycloak-dev] travis seems to be down Message-ID: A lot of builds failing in initial setup Bill From bruno at abstractj.org Wed Jul 27 17:01:47 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 27 Jul 2016 18:01:47 -0300 Subject: [keycloak-dev] travis seems to be down In-Reply-To: References: Message-ID: <20160727210147.GA3027@abstractj.org> Seems like they are fully operational[1]. I believe that this is the reason: "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." Based on my previous experiences, it happens when the build takes too long. Not really sure if that's the root cause, but I can help investigating it. [1] - https://www.traviscistatus.com/ On 2016-07-27, Bill Burke wrote: > A lot of builds failing in initial setup > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From psilva at redhat.com Wed Jul 27 17:16:49 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 27 Jul 2016 17:16:49 -0400 (EDT) Subject: [keycloak-dev] travis seems to be down In-Reply-To: <20160727210147.GA3027@abstractj.org> References: <20160727210147.GA3027@abstractj.org> Message-ID: <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> Got that error, but now the build was successful. ----- Original Message ----- From: "Bruno Oliveira" To: "Bill Burke" Cc: "keycloak-dev" Sent: Wednesday, July 27, 2016 6:01:47 PM Subject: Re: [keycloak-dev] travis seems to be down Seems like they are fully operational[1]. I believe that this is the reason: "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." Based on my previous experiences, it happens when the build takes too long. Not really sure if that's the root cause, but I can help investigating it. [1] - https://www.traviscistatus.com/ On 2016-07-27, Bill Burke wrote: > A lot of builds failing in initial setup > > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From bruno at abstractj.org Wed Jul 27 17:37:44 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 27 Jul 2016 18:37:44 -0300 Subject: [keycloak-dev] travis seems to be down In-Reply-To: <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> Message-ID: <20160727213744.GA442@abstractj.org> Seems like the balance of the Force was established again. On 2016-07-27, Pedro Igor Silva wrote: > Got that error, but now the build was successful. > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "Bill Burke" > Cc: "keycloak-dev" > Sent: Wednesday, July 27, 2016 6:01:47 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Seems like they are fully operational[1]. I believe that this is the > reason: > > "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." > > Based on my previous experiences, it happens when the build takes too > long. Not really sure if that's the root cause, but I can help > investigating it. > > [1] - https://www.traviscistatus.com/ > > On 2016-07-27, Bill Burke wrote: > > A lot of builds failing in initial setup > > > > > > Bill > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From psilva at redhat.com Wed Jul 27 19:02:51 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 27 Jul 2016 19:02:51 -0400 (EDT) Subject: [keycloak-dev] travis seems to be down In-Reply-To: <20160727213744.GA442@abstractj.org> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> Message-ID: <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> I think Travis decided to not mess with Bill :) ----- Original Message ----- From: "Bruno Oliveira" To: "Pedro Igor Silva" Cc: "Bill Burke" , "keycloak-dev" Sent: Wednesday, July 27, 2016 6:37:44 PM Subject: Re: [keycloak-dev] travis seems to be down Seems like the balance of the Force was established again. On 2016-07-27, Pedro Igor Silva wrote: > Got that error, but now the build was successful. > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "Bill Burke" > Cc: "keycloak-dev" > Sent: Wednesday, July 27, 2016 6:01:47 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Seems like they are fully operational[1]. I believe that this is the > reason: > > "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." > > Based on my previous experiences, it happens when the build takes too > long. Not really sure if that's the root cause, but I can help > investigating it. > > [1] - https://www.traviscistatus.com/ > > On 2016-07-27, Bill Burke wrote: > > A lot of builds failing in initial setup > > > > > > Bill > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Wed Jul 27 19:53:16 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 27 Jul 2016 19:53:16 -0400 Subject: [keycloak-dev] travis seems to be down In-Reply-To: <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> Message-ID: <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> Wrong... :( I still get this problem. On 7/27/16 7:02 PM, Pedro Igor Silva wrote: > I think Travis decided to not mess with Bill :) > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "Pedro Igor Silva" > Cc: "Bill Burke" , "keycloak-dev" > Sent: Wednesday, July 27, 2016 6:37:44 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Seems like the balance of the Force was established again. > > On 2016-07-27, Pedro Igor Silva wrote: >> Got that error, but now the build was successful. >> >> ----- Original Message ----- >> From: "Bruno Oliveira" >> To: "Bill Burke" >> Cc: "keycloak-dev" >> Sent: Wednesday, July 27, 2016 6:01:47 PM >> Subject: Re: [keycloak-dev] travis seems to be down >> >> Seems like they are fully operational[1]. I believe that this is the >> reason: >> >> "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." >> >> Based on my previous experiences, it happens when the build takes too >> long. Not really sure if that's the root cause, but I can help >> investigating it. >> >> [1] - https://www.traviscistatus.com/ >> >> On 2016-07-27, Bill Burke wrote: >>> A lot of builds failing in initial setup >>> >>> >>> Bill >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- > > abstractj > PGP: 0x84DC9914 From psilva at redhat.com Wed Jul 27 20:19:53 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 27 Jul 2016 20:19:53 -0400 (EDT) Subject: [keycloak-dev] travis seems to be down In-Reply-To: <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> Message-ID: <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> As Bruno suggested, the problem is probably related with the build taking too long. If you look at the first command being executed: mvn install -Pdistribution -DskipTests=true -B -V -q The -q option tells maven to run in quite mode and only show errors. Even in my laptop, if I run the command above it takes a bit more time to show any output (not too long, but more than usual). That may explain that message from Travis. Maybe we should remove -q and just log everything. That could make the builds more stable. I've forced a new build to your https://github.com/keycloak/keycloak/pull/3079 (without changing anything to .travis.yml). Now it is running. ----- Original Message ----- From: "Bill Burke" To: "Pedro Igor Silva" , "Bruno Oliveira" Cc: "keycloak-dev" Sent: Wednesday, July 27, 2016 8:53:16 PM Subject: Re: [keycloak-dev] travis seems to be down Wrong... :( I still get this problem. On 7/27/16 7:02 PM, Pedro Igor Silva wrote: > I think Travis decided to not mess with Bill :) > > ----- Original Message ----- > From: "Bruno Oliveira" > To: "Pedro Igor Silva" > Cc: "Bill Burke" , "keycloak-dev" > Sent: Wednesday, July 27, 2016 6:37:44 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Seems like the balance of the Force was established again. > > On 2016-07-27, Pedro Igor Silva wrote: >> Got that error, but now the build was successful. >> >> ----- Original Message ----- >> From: "Bruno Oliveira" >> To: "Bill Burke" >> Cc: "keycloak-dev" >> Sent: Wednesday, July 27, 2016 6:01:47 PM >> Subject: Re: [keycloak-dev] travis seems to be down >> >> Seems like they are fully operational[1]. I believe that this is the >> reason: >> >> "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." >> >> Based on my previous experiences, it happens when the build takes too >> long. Not really sure if that's the root cause, but I can help >> investigating it. >> >> [1] - https://www.traviscistatus.com/ >> >> On 2016-07-27, Bill Burke wrote: >>> A lot of builds failing in initial setup >>> >>> >>> Bill >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- > > abstractj > PGP: 0x84DC9914 From bburke at redhat.com Wed Jul 27 20:22:36 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 27 Jul 2016 20:22:36 -0400 Subject: [keycloak-dev] travis seems to be down In-Reply-To: <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> Message-ID: <1ed1dab2-db55-076a-a52e-95395da52d0e@redhat.com> How do you force a new build? On 7/27/16 8:19 PM, Pedro Igor Silva wrote: > As Bruno suggested, the problem is probably related with the build taking too long. If you look at the first command being executed: > > mvn install -Pdistribution -DskipTests=true -B -V -q > > The -q option tells maven to run in quite mode and only show errors. Even in my laptop, if I run the command above it takes a bit more time to show any output (not too long, but more than usual). That may explain that message from Travis. > > Maybe we should remove -q and just log everything. That could make the builds more stable. > > I've forced a new build to your https://github.com/keycloak/keycloak/pull/3079 (without changing anything to .travis.yml). Now it is running. > > ----- Original Message ----- > From: "Bill Burke" > To: "Pedro Igor Silva" , "Bruno Oliveira" > Cc: "keycloak-dev" > Sent: Wednesday, July 27, 2016 8:53:16 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Wrong... :( I still get this problem. > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: >> I think Travis decided to not mess with Bill :) >> >> ----- Original Message ----- >> From: "Bruno Oliveira" >> To: "Pedro Igor Silva" >> Cc: "Bill Burke" , "keycloak-dev" >> Sent: Wednesday, July 27, 2016 6:37:44 PM >> Subject: Re: [keycloak-dev] travis seems to be down >> >> Seems like the balance of the Force was established again. >> >> On 2016-07-27, Pedro Igor Silva wrote: >>> Got that error, but now the build was successful. >>> >>> ----- Original Message ----- >>> From: "Bruno Oliveira" >>> To: "Bill Burke" >>> Cc: "keycloak-dev" >>> Sent: Wednesday, July 27, 2016 6:01:47 PM >>> Subject: Re: [keycloak-dev] travis seems to be down >>> >>> Seems like they are fully operational[1]. I believe that this is the >>> reason: >>> >>> "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." >>> >>> Based on my previous experiences, it happens when the build takes too >>> long. Not really sure if that's the root cause, but I can help >>> investigating it. >>> >>> [1] - https://www.traviscistatus.com/ >>> >>> On 2016-07-27, Bill Burke wrote: >>>> A lot of builds failing in initial setup >>>> >>>> >>>> Bill >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- >> >> abstractj >> PGP: 0x84DC9914 From psilva at redhat.com Wed Jul 27 20:27:39 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 27 Jul 2016 20:27:39 -0400 (EDT) Subject: [keycloak-dev] travis seems to be down In-Reply-To: <1ed1dab2-db55-076a-a52e-95395da52d0e@redhat.com> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> <1ed1dab2-db55-076a-a52e-95395da52d0e@redhat.com> Message-ID: <1036776563.20365555.1469665659106.JavaMail.zimbra@redhat.com> There is a 'Details' link on the PR page. Click on it and you will be redirect to a page with more details about the build. There is a reload button there on the right corner of that page. ----- Original Message ----- From: "Bill Burke" To: "Pedro Igor Silva" Cc: "Bruno Oliveira" , "keycloak-dev" Sent: Wednesday, July 27, 2016 9:22:36 PM Subject: Re: [keycloak-dev] travis seems to be down How do you force a new build? On 7/27/16 8:19 PM, Pedro Igor Silva wrote: > As Bruno suggested, the problem is probably related with the build taking too long. If you look at the first command being executed: > > mvn install -Pdistribution -DskipTests=true -B -V -q > > The -q option tells maven to run in quite mode and only show errors. Even in my laptop, if I run the command above it takes a bit more time to show any output (not too long, but more than usual). That may explain that message from Travis. > > Maybe we should remove -q and just log everything. That could make the builds more stable. > > I've forced a new build to your https://github.com/keycloak/keycloak/pull/3079 (without changing anything to .travis.yml). Now it is running. > > ----- Original Message ----- > From: "Bill Burke" > To: "Pedro Igor Silva" , "Bruno Oliveira" > Cc: "keycloak-dev" > Sent: Wednesday, July 27, 2016 8:53:16 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Wrong... :( I still get this problem. > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: >> I think Travis decided to not mess with Bill :) >> >> ----- Original Message ----- >> From: "Bruno Oliveira" >> To: "Pedro Igor Silva" >> Cc: "Bill Burke" , "keycloak-dev" >> Sent: Wednesday, July 27, 2016 6:37:44 PM >> Subject: Re: [keycloak-dev] travis seems to be down >> >> Seems like the balance of the Force was established again. >> >> On 2016-07-27, Pedro Igor Silva wrote: >>> Got that error, but now the build was successful. >>> >>> ----- Original Message ----- >>> From: "Bruno Oliveira" >>> To: "Bill Burke" >>> Cc: "keycloak-dev" >>> Sent: Wednesday, July 27, 2016 6:01:47 PM >>> Subject: Re: [keycloak-dev] travis seems to be down >>> >>> Seems like they are fully operational[1]. I believe that this is the >>> reason: >>> >>> "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." >>> >>> Based on my previous experiences, it happens when the build takes too >>> long. Not really sure if that's the root cause, but I can help >>> investigating it. >>> >>> [1] - https://www.traviscistatus.com/ >>> >>> On 2016-07-27, Bill Burke wrote: >>>> A lot of builds failing in initial setup >>>> >>>> >>>> Bill >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- >> >> abstractj >> PGP: 0x84DC9914 From bruno at abstractj.org Wed Jul 27 21:45:35 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 27 Jul 2016 22:45:35 -0300 Subject: [keycloak-dev] travis seems to be down In-Reply-To: <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> Message-ID: <20160728014535.GA13976@abstractj.org> Another alternative, but you might not enjoy it, is :) Before start building Keycloak, pre-download all the '.m2' dir with the dependencies required. Second alternative, is to try some caching[1], but it may or may not work. [1] - https://docs.travis-ci.com/user/caching/ On 2016-07-27, Pedro Igor Silva wrote: > As Bruno suggested, the problem is probably related with the build taking too long. If you look at the first command being executed: > > mvn install -Pdistribution -DskipTests=true -B -V -q > > The -q option tells maven to run in quite mode and only show errors. Even in my laptop, if I run the command above it takes a bit more time to show any output (not too long, but more than usual). That may explain that message from Travis. > > Maybe we should remove -q and just log everything. That could make the builds more stable. > > I've forced a new build to your https://github.com/keycloak/keycloak/pull/3079 (without changing anything to .travis.yml). Now it is running. > > ----- Original Message ----- > From: "Bill Burke" > To: "Pedro Igor Silva" , "Bruno Oliveira" > Cc: "keycloak-dev" > Sent: Wednesday, July 27, 2016 8:53:16 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Wrong... :( I still get this problem. > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: > > I think Travis decided to not mess with Bill :) > > > > ----- Original Message ----- > > From: "Bruno Oliveira" > > To: "Pedro Igor Silva" > > Cc: "Bill Burke" , "keycloak-dev" > > Sent: Wednesday, July 27, 2016 6:37:44 PM > > Subject: Re: [keycloak-dev] travis seems to be down > > > > Seems like the balance of the Force was established again. > > > > On 2016-07-27, Pedro Igor Silva wrote: > >> Got that error, but now the build was successful. > >> > >> ----- Original Message ----- > >> From: "Bruno Oliveira" > >> To: "Bill Burke" > >> Cc: "keycloak-dev" > >> Sent: Wednesday, July 27, 2016 6:01:47 PM > >> Subject: Re: [keycloak-dev] travis seems to be down > >> > >> Seems like they are fully operational[1]. I believe that this is the > >> reason: > >> > >> "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." > >> > >> Based on my previous experiences, it happens when the build takes too > >> long. Not really sure if that's the root cause, but I can help > >> investigating it. > >> > >> [1] - https://www.traviscistatus.com/ > >> > >> On 2016-07-27, Bill Burke wrote: > >>> A lot of builds failing in initial setup > >>> > >>> > >>> Bill > >>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > > > > abstractj > > PGP: 0x84DC9914 > -- abstractj PGP: 0x84DC9914 From joakim.lofgren at gmail.com Thu Jul 28 03:05:29 2016 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Thu, 28 Jul 2016 07:05:29 +0000 Subject: [keycloak-dev] Brute force lock out and password reset error In-Reply-To: <20160727121655.GA22977@abstractj.org> References: <20160726113453.GC29719@abstractj.org> <20160727121655.GA22977@abstractj.org> Message-ID: Well everything can be automated, yes. I'll explain in more detail. 1. Hacker or myself fails to login 3 times 2. Brute force detection temporarily disables my account 3. I enter my email in the reset password form and submit. 4. An email lands in my inbox 5. Account is still temporarily disabled 6. I prove my identity (or at least access to the email account) and click the reset link in the email 7. Account is unlocked and I get a login session and prompted to update my password This prevents someone from continuously trying to hack my account and thus keeping me locked out of my account. It also provides a better experience for someone who has just forgotten his or her password and attempts to login a few too many times. Just waiting for the account to unlock so the password reset works again isn't more secure in my mind. Just more tedious. Thoughts? On Wed, Jul 27, 2016, 14:16 Bruno Oliveira wrote: > On 2016-07-27, Joakim L?fgren wrote: > > Not if you have to click the link in the email for it to be unlocked ? > > You know that can be easily automated, right? > > > > > On Tue, Jul 26, 2016, 13:34 Bruno Oliveira wrote: > > > > > On 2016-07-26, Joakim L?fgren wrote: > > > > Hey, > > > > > > > > I noticed that if you get your account temporarily locked due to the > > > brute > > > > force detection then you cannot reset your password until the > temporary > > > > locked has been lifted. > > > > > > > > Is this behaviour intended ? > > > > > > From what I can tell, this is how it works today and that's > intentional. > > > I think that in order to enable password reset for blocked accounts, > > > rate limiting for password reset should be introduced, otherwise, an > > > attacker could try it again. > > > > > > > > > > > We've gotten a few users that become confused when they do not > receive a > > > > reset password email, and thus contact us asking for help. > > > > > > > > > > > > Sincerely, > > > > Joakim > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160728/e495ce08/attachment.html From gambol99 at gmail.com Thu Jul 28 05:01:06 2016 From: gambol99 at gmail.com (gambol) Date: Thu, 28 Jul 2016 10:01:06 +0100 Subject: [keycloak-dev] Fwd: Authenticated base on roles In-Reply-To: References: Message-ID: Hiya Assuming you have a realm with x client defined and each have a APP-USER role. Is there a way to authenticate a user only if the user have the role associated? ... Obviously I can check the check the access token, or place a proxy in-front which does that for me, but is there a native way of saying ask for this scope and if you don't have it you are denied Best Regards .. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160728/752eeece/attachment.html From bruno at abstractj.org Thu Jul 28 08:02:05 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 28 Jul 2016 09:02:05 -0300 Subject: [keycloak-dev] Brute force lock out and password reset error In-Reply-To: References: <20160726113453.GC29719@abstractj.org> <20160727121655.GA22977@abstractj.org> Message-ID: <20160728120205.GA27219@abstractj.org> Hi Joakim, What you're suggesting makes sense. I'm just trying to say that in order to have it implemented, we should have a rate limit for password resets. Anyways, please file a jira for it. On 2016-07-28, Joakim L?fgren wrote: > Well everything can be automated, yes. > > I'll explain in more detail. > > 1. Hacker or myself fails to login 3 times > 2. Brute force detection temporarily disables my account > 3. I enter my email in the reset password form and submit. > 4. An email lands in my inbox > 5. Account is still temporarily disabled > 6. I prove my identity (or at least access to the email account) and click > the reset link in the email > 7. Account is unlocked and I get a login session and prompted to update my > password > > This prevents someone from continuously trying to hack my account and thus > keeping me locked out of my account. > > It also provides a better experience for someone who has just forgotten his > or her password and attempts to login a few too many times. > > Just waiting for the account to unlock so the password reset works again > isn't more secure in my mind. Just more tedious. > > Thoughts? > > On Wed, Jul 27, 2016, 14:16 Bruno Oliveira wrote: > > > On 2016-07-27, Joakim L?fgren wrote: > > > Not if you have to click the link in the email for it to be unlocked ? > > > > You know that can be easily automated, right? > > > > > > > > On Tue, Jul 26, 2016, 13:34 Bruno Oliveira wrote: > > > > > > > On 2016-07-26, Joakim L?fgren wrote: > > > > > Hey, > > > > > > > > > > I noticed that if you get your account temporarily locked due to the > > > > brute > > > > > force detection then you cannot reset your password until the > > temporary > > > > > locked has been lifted. > > > > > > > > > > Is this behaviour intended ? > > > > > > > > From what I can tell, this is how it works today and that's > > intentional. > > > > I think that in order to enable password reset for blocked accounts, > > > > rate limiting for password reset should be introduced, otherwise, an > > > > attacker could try it again. > > > > > > > > > > > > > > We've gotten a few users that become confused when they do not > > receive a > > > > > reset password email, and thus contact us asking for help. > > > > > > > > > > > > > > > Sincerely, > > > > > Joakim > > > > > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > -- > > > > > > > > abstractj > > > > PGP: 0x84DC9914 > > > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > -- abstractj PGP: 0x84DC9914 From jdennis at redhat.com Thu Jul 28 09:30:19 2016 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Jul 2016 09:30:19 -0400 Subject: [keycloak-dev] Fwd: Authenticated base on roles In-Reply-To: References: Message-ID: On 07/28/2016 05:01 AM, gambol wrote: > Assuming you have a realm with x client defined and each have a APP-USER > role. Is there a way to authenticate a user only if the user have the > role associated? ... Authentication is the process of proving an identity. You can't know what roles a user has until after authentication. -- John From psilva at redhat.com Thu Jul 28 11:11:35 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 28 Jul 2016 11:11:35 -0400 (EDT) Subject: [keycloak-dev] travis seems to be down In-Reply-To: <20160728014535.GA13976@abstractj.org> References: <20160727210147.GA3027@abstractj.org> <2011162883.20344066.1469654209191.JavaMail.zimbra@redhat.com> <20160727213744.GA442@abstractj.org> <734242238.20355899.1469660571274.JavaMail.zimbra@redhat.com> <59c046c4-9409-1f13-c63a-6d6744bdd402@redhat.com> <427646040.20364950.1469665193602.JavaMail.zimbra@redhat.com> <20160728014535.GA13976@abstractj.org> Message-ID: <2135599354.20603917.1469718695315.JavaMail.zimbra@redhat.com> Let's see what Stian thinks about it :) For me, it is also an option. ----- Original Message ----- From: "Bruno Oliveira" To: "Pedro Igor Silva" Cc: "Bill Burke" , "keycloak-dev" Sent: Wednesday, July 27, 2016 10:45:35 PM Subject: Re: [keycloak-dev] travis seems to be down Another alternative, but you might not enjoy it, is :) Before start building Keycloak, pre-download all the '.m2' dir with the dependencies required. Second alternative, is to try some caching[1], but it may or may not work. [1] - https://docs.travis-ci.com/user/caching/ On 2016-07-27, Pedro Igor Silva wrote: > As Bruno suggested, the problem is probably related with the build taking too long. If you look at the first command being executed: > > mvn install -Pdistribution -DskipTests=true -B -V -q > > The -q option tells maven to run in quite mode and only show errors. Even in my laptop, if I run the command above it takes a bit more time to show any output (not too long, but more than usual). That may explain that message from Travis. > > Maybe we should remove -q and just log everything. That could make the builds more stable. > > I've forced a new build to your https://github.com/keycloak/keycloak/pull/3079 (without changing anything to .travis.yml). Now it is running. > > ----- Original Message ----- > From: "Bill Burke" > To: "Pedro Igor Silva" , "Bruno Oliveira" > Cc: "keycloak-dev" > Sent: Wednesday, July 27, 2016 8:53:16 PM > Subject: Re: [keycloak-dev] travis seems to be down > > Wrong... :( I still get this problem. > > > On 7/27/16 7:02 PM, Pedro Igor Silva wrote: > > I think Travis decided to not mess with Bill :) > > > > ----- Original Message ----- > > From: "Bruno Oliveira" > > To: "Pedro Igor Silva" > > Cc: "Bill Burke" , "keycloak-dev" > > Sent: Wednesday, July 27, 2016 6:37:44 PM > > Subject: Re: [keycloak-dev] travis seems to be down > > > > Seems like the balance of the Force was established again. > > > > On 2016-07-27, Pedro Igor Silva wrote: > >> Got that error, but now the build was successful. > >> > >> ----- Original Message ----- > >> From: "Bruno Oliveira" > >> To: "Bill Burke" > >> Cc: "keycloak-dev" > >> Sent: Wednesday, July 27, 2016 6:01:47 PM > >> Subject: Re: [keycloak-dev] travis seems to be down > >> > >> Seems like they are fully operational[1]. I believe that this is the > >> reason: > >> > >> "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself." > >> > >> Based on my previous experiences, it happens when the build takes too > >> long. Not really sure if that's the root cause, but I can help > >> investigating it. > >> > >> [1] - https://www.traviscistatus.com/ > >> > >> On 2016-07-27, Bill Burke wrote: > >>> A lot of builds failing in initial setup > >>> > >>> > >>> Bill > >>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > > > > abstractj > > PGP: 0x84DC9914 > -- abstractj PGP: 0x84DC9914 From joakim.lofgren at gmail.com Fri Jul 29 04:44:51 2016 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Fri, 29 Jul 2016 08:44:51 +0000 Subject: [keycloak-dev] Brute force lock out and password reset error In-Reply-To: <20160728120205.GA27219@abstractj.org> References: <20160726113453.GC29719@abstractj.org> <20160727121655.GA22977@abstractj.org> <20160728120205.GA27219@abstractj.org> Message-ID: KEYCLOAK-3371 On Thu, Jul 28, 2016, 14:02 Bruno Oliveira wrote: > Hi Joakim, > > What you're suggesting makes sense. I'm just trying to say that in > order to have it implemented, we should have a rate limit for password > resets. > > Anyways, please file a jira for it. > > On 2016-07-28, Joakim L?fgren wrote: > > Well everything can be automated, yes. > > > > I'll explain in more detail. > > > > 1. Hacker or myself fails to login 3 times > > 2. Brute force detection temporarily disables my account > > 3. I enter my email in the reset password form and submit. > > 4. An email lands in my inbox > > 5. Account is still temporarily disabled > > 6. I prove my identity (or at least access to the email account) and > click > > the reset link in the email > > 7. Account is unlocked and I get a login session and prompted to update > my > > password > > > > This prevents someone from continuously trying to hack my account and > thus > > keeping me locked out of my account. > > > > It also provides a better experience for someone who has just forgotten > his > > or her password and attempts to login a few too many times. > > > > Just waiting for the account to unlock so the password reset works again > > isn't more secure in my mind. Just more tedious. > > > > Thoughts? > > > > On Wed, Jul 27, 2016, 14:16 Bruno Oliveira wrote: > > > > > On 2016-07-27, Joakim L?fgren wrote: > > > > Not if you have to click the link in the email for it to be unlocked > ? > > > > > > You know that can be easily automated, right? > > > > > > > > > > > On Tue, Jul 26, 2016, 13:34 Bruno Oliveira > wrote: > > > > > > > > > On 2016-07-26, Joakim L?fgren wrote: > > > > > > Hey, > > > > > > > > > > > > I noticed that if you get your account temporarily locked due to > the > > > > > brute > > > > > > force detection then you cannot reset your password until the > > > temporary > > > > > > locked has been lifted. > > > > > > > > > > > > Is this behaviour intended ? > > > > > > > > > > From what I can tell, this is how it works today and that's > > > intentional. > > > > > I think that in order to enable password reset for blocked > accounts, > > > > > rate limiting for password reset should be introduced, otherwise, > an > > > > > attacker could try it again. > > > > > > > > > > > > > > > > > We've gotten a few users that become confused when they do not > > > receive a > > > > > > reset password email, and thus contact us asking for help. > > > > > > > > > > > > > > > > > > Sincerely, > > > > > > Joakim > > > > > > > > > > > _______________________________________________ > > > > > > keycloak-dev mailing list > > > > > > keycloak-dev at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > -- > > > > > > > > > > abstractj > > > > > PGP: 0x84DC9914 > > > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160729/353090a3/attachment.html From abstractj at redhat.com Mon Jul 18 17:53:44 2016 From: abstractj at redhat.com (Bruno Oliveira) Date: Mon, 18 Jul 2016 21:53:44 -0000 Subject: [keycloak-dev] PAM conversations- Custom login form Message-ID: <20160718215339.GB654@redhat.com> Good morning, Today to authentication against PAM with just simple username/password I implemented UserFederationProvider and added the proper PAM login to validCredentials[1]. This covers the most basic scenario. Now I would like to cover a more complex scenario like OTP and change the flow a little bit like this: 1. User providers her username 2. The next screen asks to provide how many factor our user has(For example: OTP, password). We just don't know, PAM will tell what's next. 3. We authenticate against it To see in practice against FreeIPA server, I just recorded it for a practical example[2]. What would be the best approach to implement this flow? I was considering to move my authentication logic out of SSSD federation provider and create a PAM authenticator. Does it make sense? [1] - http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel- [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a -- abstractj PGP: 0x84DC9914