if you are interested in writing this cli in javascript, there is this little project i had been working on , https://github.com/bucharest-gold/keycloak-admin-client On Mon, Jun 27, 2016 at 7:48 AM, Marko Strukelj <mstrukel(a)redhat.com&gt; 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-cHkpTURIlUk... > > > 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. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

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-cHkpTURIlUk... > > > 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. * 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.

* I don't see anything in your document on how to specify the SAML metadata. * 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.

* 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.

* 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 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.

* The tool should not have significant dependencies.

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > On 27 June 2016 at 21:26, John Dennis <jdennis(a)redhat.com&gt; 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-cHkpTURIlUk... >> > >> > >> > 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-regi... 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. 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.

On 28 June 2016 at 11:40, Marko Strukelj <mstrukel(a)redhat.com&gt; wrote: > > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> >> >> On 27 June 2016 at 21:26, John Dennis <jdennis(a)redhat.com&gt; 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-cHkpTURIlUk... >>> > >>> > >>> > 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-regi... > > 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-regi... > ) > > 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 <client id> --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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >

_______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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 <bruno(a)abstractj.org&gt; 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 <mstrukel(a)redhat.com&gt; wrote: > > > > > > > > > > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen < > sthorger(a)redhat.com&gt; > > > wrote: > > > > > >> > > >> > > >> On 27 June 2016 at 21:26, John Dennis <jdennis(a)redhat.com&gt; 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-cHkpTURIlUk... > > >>> > > > >>> > > > >>> > 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-regi... > > > > > > 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-regi... > > > ) > > > > > > 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 <client id> --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(a)lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >>> > > >> > > >> > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > > abstractj > PGP: 0x84DC9914 >

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 <sthorger(a)redhat.com&gt; 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 <bruno(a)abstractj.org&gt; 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 <mstrukel(a)redhat.com&gt; wrote: > >> > > >> > > > >> > > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen < > >> sthorger(a)redhat.com&gt; > >> > > wrote: > >> > > > >> > >> > >> > >> > >> > >> On 27 June 2016 at 21:26, John Dennis <jdennis(a)redhat.com&gt; 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-cHkpTURIlUk... > >> > >>> > > >> > >>> > > >> > >>> > 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-regi... > >> > > > >> > > 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-regi... > >> > > ) > >> > > > >> > > 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 <client id> --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(a)lists.jboss.org > >> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >>> > >> > >> > >> > >> > >> > > > >> > >> > _______________________________________________ > >> > keycloak-dev mailing list > >> > keycloak-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> > > > > -- abstractj PGP: 0x84DC9914

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.

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

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 <bruno(a)abstractj.org&gt; 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 <sthorger(a)redhat.com&gt; 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 <bruno(a)abstractj.org&gt; 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 <mstrukel(a)redhat.com&gt; > > wrote: > > > >> > > > > >> > > > > > >> > > > > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen < > > > >> sthorger(a)redhat.com&gt; > > > >> > > wrote: > > > >> > > > > > >> > >> > > > >> > >> > > > >> > >> On 27 June 2016 at 21:26, John Dennis <jdennis(a)redhat.com&gt; > > 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-cHkpTURIlUk... > > > >> > >>> > > > > >> > >>> > > > > >> > >>> > 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-regi... > > > >> > > > > > >> > > 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-regi... > > > >> > > ) > > > >> > > > > > >> > > 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 <client id> --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(a)lists.jboss.org > > > >> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >> > >>> > > > >> > >> > > > >> > >> > > > >> > > > > > >> > > > >> > _______________________________________________ > > > >> > keycloak-dev mailing list > > > >> > keycloak-dev(a)lists.jboss.org > > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >> > > > >> > > > >> -- > > > >> > > > >> abstractj > > > >> PGP: 0x84DC9914 > > > >> > > > > > > > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > -- abstractj PGP: 0x84DC9914

Sorry about the duplicated e-mail. On Wed, Jun 29, 2016, 11:21 PM Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > On 30 June 2016 at 08:08, Bruno Oliveira <bruno(a)abstractj.org&gt; 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.

> >> >> 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 <bruno(a)abstractj.org&gt; 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 <sthorger(a)redhat.com&gt; >> 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 <bruno(a)abstractj.org&gt; >> 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 <mstrukel(a)redhat.com >> > >> > > wrote: >> > > > >> > >> > > > >> > > >> > > > >> > > >> > > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen < >> > > > >> sthorger(a)redhat.com&gt; >> > > > >> > > wrote: >> > > > >> > > >> > > > >> > >> >> > > > >> > >> >> > > > >> > >> On 27 June 2016 at 21:26, John Dennis <jdennis(a)redhat.com&gt; >> > > 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-cHkpTURIlUk... >> > > > >> > >>> > >> > > > >> > >>> > >> > > > >> > >>> > 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-regi... >> > > > >> > > >> > > > >> > > 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-regi... >> > > > >> > > ) >> > > > >> > > >> > > > >> > > 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 <client id> --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(a)lists.jboss.org >> > > > >> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > >> > >>> >> > > > >> > >> >> > > > >> > >> >> > > > >> > > >> > > > >> >> > > > >> > _______________________________________________ >> > > > >> > keycloak-dev mailing list >> > > > >> > keycloak-dev(a)lists.jboss.org >> > > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > >> >> > > > >> >> > > > >> -- >> > > > >> >> > > > >> abstractj >> > > > >> PGP: 0x84DC9914 >> > > > >> >> > > > > >> > > > > >> > > >> > > -- >> > > >> > > abstractj >> > > PGP: 0x84DC9914 >> > > >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> >

On 06/28/2016 01:35 AM, Stian Thorgersen wrote: > 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? > I think these are all things previously discussed, but here is a recap: * Force POST Binding must be enabled (saml.force.post.binding). This is an example of where the client registration service and the REST API have different behavior. One of them produces a ClientRepresentation with this SAML attribute defaulted to False and the other defaults it to True. I believe the consensus is that this flag needs to be removed because it's inconsistent with the SAML spec. On the client side we need to know if we are talking to a server which implements the flag or not, so far we do not have that check implemented. * Adding all the SAML binding endpoints to the list of Redirect URI's. The endpoint's are present in the SAML Metadata sent to Keycloak but for some reason they are ignored. A related issue (not specific to client registration) is significant parts of the SAML metadata is ignored and discarded (among these are the endpoints) * Adding the group attribute mapper to the client. A reasonable argument could be made this is not part of initial client registration but rather a post registration configuration operation. However without group information many SAML SP's will not operate correctly because groups are typically used to make authorization access decisions. Therefore we must assure a new client will return group attribute information.