Authorization Code Flow as Default for Javascript?
by Josh Cain
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
<https://keycloak.gitbooks.io/securing-client-applications-guide/content/v...>
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
> <http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth> flow.
>
However, the OIDC spec
<http://openid.net/specs/openid-connect-core-1_0.html> 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 <https://tools.ietf.org/html/rfc6749>, 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
9 years, 3 months
Move tools from testsuite/integration into testsuite/tools
by Stian Thorgersen
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.
9 years, 3 months
Feedback on authz services
by Stian Thorgersen
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/discus...
)
* 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?
9 years, 3 months
Debugging with an IDE configuration
by Erik Berdonces Bonelo
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
9 years, 3 months
Reuse of OpenID Connect IDP
by Michael Furman
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
9 years, 3 months
Support UTF-8 encoding theme message properites
by Hiroyuki Wada
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(j...
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.
9 years, 3 months
Admin Realm in keycloak-server.json
by Stan Silvert
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"
9 years, 3 months
Keycloak spring security adapter - possible to set http / pool timeouts for outgoing connections?
by Christian Schwarz
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
9 years, 3 months
Keycloak SSL Reverse Proxy settings
by gambol
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
—
<http-listener name="default" socket-binding="http"
proxy-address-forwarding="true" redirect-socket="proxy-https"/>
...
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="proxy-https" port="443"/> <---
...
------------------------------
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
9 years, 3 months
