Improved CSP support
by Johannes Knutsen
Hi,
I am currently looking at improvements in the Content Security Policy
(CSP) support.
In our deployment, we have security requirements stating that a CSP
header should be used and inline scripts, styles and resources should
be blocked. For example by setting a CSP value like default-src
'self';.
Such a policy breaks Keycloak's manipulation of the browser history
implemented in the BrowserHistoryHelper, since the
JavascriptHistoryReplace injects an inline JavaScript.
The simplest workaround is to also inject a nonce value or SHA hash of
the script to the existing CSP header.
However, while implementing this, I found that a CSP nonce in general
would be nice to have available in any template context. This will
also make it easier to migrate the default Keycloak theme to support
stricter security policies.
An example implementation can be found here:
https://github.com/knutz3n/keycloak/commit/c6cfb3efa2942d7569066c0e4bd90a...
Would you be interested in merging a change like the one above? If
not, what is your view on how to allow stricter content security
policies?
Tests and documentation is currently missing, but I will add both if
this is something you would consider merging.
As a note, I have also done some work on supporting a strict CSP value
for the default theme. But there are some issues with included 3rd
party scripts which must/should be resolved. Let me know if you want
more details regarding this.
Best regards,
Johannes Knutsen
6 years, 2 months
Keycloak Proxy Rename
by Bruno Oliveira
Good afternoon,
We are considering to transfer or fork the keycloak-proxy[1] to Keycloak
organization. In order to accomplish that, I've been working with Rohith
updating some of its dependencies[2].
While discussing with our team, we reached the conclusion that call it a
proxy could potentially increase the scope of the project and also give
people the wrong idea. Because would be expected things like load balancing,
rate limiting, and other features. That's not what we want right now.
I would like to gather some feedback from the community before we move forward.
So please vote on the following Doodle:
https://doodle.com/poll/gux626ktscgpr96t
Also, feel free to suggest other names and it will be included.
[1] - https://github.com/gambol99/keycloak-proxy
[2] - https://issues.jboss.org/browse/KEYCLOAK-7265
--
abstractj
6 years, 4 months
Proposal - use Ant Plugin for generating JKS files
by Sebastian Laskawiec
Hey,
Together with Sebi we are working on Certificate-based authentication for
the clients. Our work will require adding at least 2-3 keystores to the
codebase with different DNs and I think this might be a good opportunity to
revisit the way we handle JKS files in the tests.
Currently we push JKS files directly into our repo, which has a couple of
drawbacks:
- it is hard to figure out what's inside the JKS, it requires looking up
for password (usually in some JSON configuration file or hardcoded in the
test) and using keytool (or some similar one) to explore its content.
- It is not git-friendly. Every time we update JKS content we effectively
store another binary file (git doesn't understand binary file changes and
can not diff it).
- we use many different naming and password schemes in our tests.
- it is hard to migrate all keystores to pkcs12 at the same time (JKS
format is deprecated) [0]
I believe most of the issues could be addressed by generating JKS files on
the fly - during the build. In Infinispan we did it with Maven Ant Plugin
[1]. I already created a very limited POC for Keycloak and you can check it
out here [2]. Unfortunately, the process of reverse engineering all those
files is quite time-consuming, so I would like to know your opinion before
moving on.
Of course, generating JKS files on the fly has some drawbacks:
- It increases build time (~1s per keytool invocation, and we probably will
have more than 30 of them).
- it makes testing from IDE a bit harder, you need to run Maven and process
test resources before doing anything. A common workaround is to use `mvn
clean install -DskipTests` and then opening your IntelliJ.
Please let me know what you think.
Thanks,
Sebastian
[0]
https://blogs.oracle.com/jtc/jdk9-keytool-transitions-default-keystore-to...
[1]
https://github.com/infinispan/infinispan/blob/master/server/integration/t...
[2] https://github.com/keycloak/keycloak/pull/5410
6 years, 4 months
Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
by 乗松隆志 / NORIMATSU，TAKASHI
Hello Sebastian,
I'm looking forward to your work, and I would be happy if I could make some contribution after finishing your work.
Best regards,
Takashi Norimatsu
Hitachi Ltd.,
----------
From: Sebastian Laskawiec <slaskawi(a)redhat.com>
Sent: Thursday, July 26, 2018 5:24 PM
To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com>
Cc: keycloak-dev(a)lists.jboss.org
Subject: [!]Re: [keycloak-dev] OAuth 2.0 Mutual TLS Client Authentication
Hey Takashi,
Thanks a lot for the interest in contributing Keycloak!
Sebi and I are working on this topic currently. We plan to reuse some bits of the User x509 Authentication and bring them to the client. We planned the implementation for this sprint, so it *should* be ready in ~3 weeks.
More comments inlined.
Thanks,
Sebastian
On Thu, Jul 26, 2018 at 1:23 AM 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com> wrote:
Hello,
As for mentioned in https://issues.jboss.org/browse/KEYCLOAK-7512 and https://issues.jboss.org/browse/KEYCLOAK-7635, Is there anyone who currently implements OAuth 2.0 Mutual TLS Client Authentication defined in https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2 ?
We also have additional requirement - allow to authenticate client without "client_id" being sent (we need to extract it from the Certificate obtained during TLS Handshake). This is required for OpenShift integration.
If no one does it, I would like to try to implement this feature. What do you think about it ?
Also, In https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2, two types of OAuth 2.0 Mutual TLS Client Authentication are defined, for PKI and for Self-Signed Certificate.
I would be happy if you who are interested in this feature tell me which you like better.
As far as I know, we won't be touching self-registering clients. So maybe once we are done (let's assume that will happen in ~3 weeks), you could take it over and look into that?
BTW, as for now, we will be implementing everything in this branch: https://github.com/sebastienblanc/keycloak/tree/client-x509 (currently, it contains an empty Authenticator but we will be adding bits and pieces to it).
Best regards,
Takashi Norimatsu
Hitachi Ltd.,
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6 years, 4 months
Keycloak URL and backchannel requests
by Stian Thorgersen
Keycloak needs to know its public URL for a number of reasons. For example
in the OIDC well-known endpoint, issuer in tokens and emails sent to users.
At the moment we retrieve this from the request headers and have documented
how to block requests with invalid URLs (
https://www.keycloak.org/docs/latest/server_admin/index.html#host). The
latter is important in production installations.
There's two problems with the current approach:
1) Clients in the same subnet can't use internal IP to communicate with
Keycloak
2) Configuring the valid URLs is an important step to secure a production
installation, but the current approach is probably not well known and is
rather messy to configure
I propose we introduce an BaseURL SPI to allow a flexible way to determine
the base URL. We would add two implementations OOTB:
1) Request - this would be set as the default-provider and would determine
the base url from request headers as we do today
2) Fixed - this would allow setting a hardcoded public URL
In standalone.xml it would look like this:
<spi name="baseURL">
<default-provider>request</default-provider>
<provider name="fixed">
<properties>
<property name="baseURL" value="localhost:8080/auth"/>
</properties>
</provider>
</spi>
For production the default-provider should be changed to fixed and the
baseURL value should be changed. This can be handled either through manual
editing standalone.xml or with jboss-cli.
Once this is incorporated it will make it easy to add support for
backchannel URL back to the adapters to allow adapters to use internal IP
address when communicating with Keycloak.
Implementation shouldn't be hard. It's mainly about making sure that
UriInfo is retrieved from KeycloakSession#KeycloakContext and not injected
directly.
If anyone has more complex requirements for determining the public URL they
can implement their own provider to handle it.
One thing I'm not sure about is if it's common to use different URLs for
different realms. If that's the case we may consider adding some support
for mapping different realms to different baseURLs. I don't think this is
common though.
6 years, 5 months
Re: [keycloak-dev] [keycloak-user] Sharing default configuration for keycloak deployment
by Dmitry Telegin
Hi,
Is it correct that you're shipping vanilla Keycloak distro with your application, and you want to apply configuration changes as easy as possible?
You should be considering the following tools:
$KEYCLOAK/bin/add-user-keycloak.sh (to add admin user)
$KEYCLOAK/bin/kcadm.sh (to create realms and virtually everything else in Keycloak; remember you'll need to spin it up first)
$KEYCLOAK/bin/jboss-cli.sh (to install JDBC driver, configure database etc.)
Cheers,
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info(a)acutus.pro
On Wed, 2018-07-25 at 12:17 +0530, Test Oauth wrote:
> I am shipping Keycloak with my application and there is some default
> configuration that I have done. I want to ship this default configuration
> (like admin name/password, realm names etc) with my application so that the
> customers can bring the basic authentication flow up with a single click
> (of probably a batch file).
>
> Is there a way to do this?
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
6 years, 5 months
Migration status of Keycloak generic adapter dependencies
by Bruno Oliveira
Good night,
I've been working on the migration of the dependencies inside keycloak-proxy
(to be renamed to keycloak-generic-adapter) from Rohith's fork to its
respective upstream dependencies.
While doing the migration I found a blocker that's holding us from
move the codebase to Keycloak organization. This piece of code:
https://github.com/gambol99/keycloak-proxy/blob/master/server.go#L645-L719.
We could continue to pursue this, but that would gonna take more time.
Or we can just, move to go-oidc upstream v1 which can be fast and simple
and later we consider v2.
I believe that SkipClientIDCheck made a lot of sense when we had this
idea of having a proxy for Keycloak. But now things had changed and
we agreed that we do not aim to provide all proxy features, which
includes SkipClientIDCheck.
This does not mean that in the future we're not going to revisit this.
But we have to move forward and having working code can be better than
perfection.
Just in case you have interest on this,here's the PR which the changes
I mentioned: https://github.com/gambol99/keycloak-proxy/pull/407
Thoughts?
--
abstractj
6 years, 5 months
SAML users should not be identified by SAML:NameID
by Daniel Teixeira
Hello,
Seems like Keycloak always uses the saml:NameID to identify a SAML user.
In org.keycloak.broker.saml.SAMLEndpoint we see:
BrokeredIdentityContext identity = new
BrokeredIdentityContext(subjectNameID.getValue());
...
identity.setUsername(subjectNameID.getValue());
However this is not a good practice, see recommendations here:
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html
*SPs MUST NOT require the presence of a <saml:NameID> element and MUST NOT
rely on the content of this element for long term identification of
subjects; <saml:Attribute> elements MUST be used for this purpose in
the *manner
detailed below.
IMO, Keycloak should provide a field when configuring an iDP to choose the
custom attribute to "identify" a user. This can be mail attribute for
example (urn:oid:0.9.2342.19200300.100.1.3). But should not take this
information from saml:NameID
Is there anyway to override this in Keycloak?
Should I create a JIRA issue?
Best regards,
Daniel Teixeira
6 years, 5 months
