Re: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing
by 乗松隆志 / NORIMATSU，TAKASHI
Hello,
Thank you for your comments.
I think it might be better to determine which kind of Token Signature Provider be used by not parsing JWS, for example, looking up Client or Realm settings.
This PR might have impacts on keycloak's performance because it has parsed JWS to determine it every time keycloak receives JWS Token.
As for existing Key Provider, I've already implemented ECDSA Key Provider (for only signing) in this PR. Therefore, I could contribute it.
As for Token Signature SPI, I agree with you. I hope I would like to implement this SPI's provider for ES256 at first and PS256 in the future.
I think it is the best way that keycloak's core committers design and implement this Token Signature SPI.
However, if they do not have yet such a plan to do that at this time and in the future, I would like to give some ideas on Token Signature SPI. How do you think about that?
Best regards,
Takashi Norimatsu
Hitachi Ltd.,
From: Stian Thorgersen <sthorger(a)redhat.com>
Sent: Tuesday, May 29, 2018 4:40 PM
To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com>
Cc: keycloak-dev(a)lists.jboss.org
Subject: [!]Re: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing
Hi,
I haven't had time to look at your PR in detail yet, but the way it should work is:
* We need to add a Token Signature SPI that can sign and validate token signatures
* RSA signing should be refactored into a Token Signature provider
* Realm should have a default signing algorithm. Admin console should allow admins to select from any supported algorithm by listing TokenSignatureSPI providers
* Clients should be able to override the signing algorithm
* When verifying signatures in the Keycloak server we should check what the method is for the client (or realm if client doesn't override) and only allow that specific algorithm and nothing else
* We may want to consider adding an option to client adapters to specify the expected signing algorithm as well
* We also need additional key providers. It looks like you've already added this
* We need to make sure that keys are only used for the correct purpose (correct algorithm and if it's for signing or encrypting). I think this is already covered though
On 25 May 2018 at 05:26, 乗松隆志 / NORIMATSU，TAKASHI <mailto:takashi.norimatsu.ws@hitachi.com> wrote:
I'd like to use more secure JWS signature algorithm in the environment where the high security level is required such as the financial industry.
According to the following RFCs, RSASSA-PSS to which PS256 follows is recommended on behalf of RSASSA-PKCS1-v1_5 to which RS256 follows.
https://clicktime.symantec.com/a/1/fIIShrle28DIlWvWduZOOVGDLk3xC_-rnn6V7E...
However, according to the following RFC, ES256 is "Recommended+" while PS256 is "Optional".
https://clicktime.symantec.com/a/1/s_2w8zdHH2DoCkMCU7h9NMxUrcVZyNjiGxV6Me...
Moreover, it is said that Elliptic Curve based algorithms have an advantage against RSA base algorithms in volume of its computation.
Therefore, I've tried to make keycloak support ES256 JWS signature along with existing RS256 one.
I've found that it seemed to be relatively easy to implement software components for ES256 JWS signature such as Signature Provider and Key Provider.
However, it seemed to be difficult to implement codes actually calling these providers. The reasons is as follows.
* a lot of places have called these singing and verifying providers.
* such the places have been hard-coded in RSA algorithm specific.
To deal with them, the following ideas have hit on me
1. replace RSA algorithm specific codes with signature algorithm independent codes.
2. re-design JWS signing and verifying scheme on high level.
I'm not familiar with keycloak internals, so I've implemented ES256 JWS signature support on #1 basis experimentally.
I'm not sure whether this way is appropriate or not. I'm very happy if keycloak specialists consider #2 or review my implementation based on #1.
I've issued PR as WIP. Please refer to the following in detail.
https://clicktime.symantec.com/a/1/G-XuERmswRIcQ_MQA72oK1EJuT0Y48iac1Lbbs...
Best regards,
Takashi Norimatsu
Hitachi Ltd.,
_______________________________________________
keycloak-dev mailing list
mailto:keycloak-dev@lists.jboss.org
https://clicktime.symantec.com/a/1/LBlgE63-JxZCbiegUCPqUTy7Oeq2A8tzZfOiWv...
8 years
Re: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator)
by 乗松隆志 / NORIMATSU，TAKASHI
Hello,
I've encountered the same problem and gave up.
At that time, the naive idea had hit on me.
* prepare some concurrently accessible singleton (line KeycloakDeployment) from OAuthRequestAuthenticator
* store generated codeVerifier on it with state parameter value as its key.
But, considering the nature of codeVerifier, the followings are required for such the store
* codeVerifier should be treated the same secure levels as client credentials
* codeVerifier should be short-lived and deleted after its life the same as Authorization Code
Therefore, It might be better to create an tentative instance whose lifetime is between issuing Authorization Code Request and issuing Token Request. And, it should be identified and only accessible from the session instance who issued Authorization Code Request.
However, I'm afraid it might be difficult to accomplish it in generic fashion. We need to implement the above each type of client adapter.
Best regards,
Takashi Norimatsu
Hitachi Ltd.,
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of Thomas Darimont
Sent: Wednesday, May 30, 2018 9:02 AM
To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator)
Hi there,
I was recently playing with the PKCE support in Keycloak (server) which worked quite well.
However the support for client / adapters seems to be quite limited at the moment...
I think support for PKCE to all? java adapters could be added quite easily
- I could provide a
PR but I'm currently stuck with finding a generic way to store the codeVerifier generated for the login redirect for later retrival for the code2token exchange.
Do you have any recommendations for this?
I created the following JIRA issue (with some comments) to track this:
https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4...
Cheers,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUd...
8 years, 1 month
KEYCLOAK-2606 - Browsertab-Support for Cordova
by Gregor Tudan
Hi there,
I would like to pick up an old issue: KEYCLOAK-2606<https://issues.jboss.org/browse/KEYCLOAK-2606>
Our current app uses Keycloak with the Cordova In-App-Browser. Technically this works fine, but the user experience is … uhmm … awful. The page renders quiet slow and has focus issues.
I’d love to help getting some support for the browser-tab. I started porting the ionic sample app to browertabs, but would like to check back with you before doing something stupid.
The idea is:
1. In Keycloak.js Cordova Adapter check if browertab is supported, else fall back to in-app-browser
2. Open the login-page with the In-App-Browser (leaving the app)
3. Register a custom-url-scheme and configure it as redirect url (i.e. keycloakapp://). We’ll need another Cordova plugin for this (i.e. deep links). The Cordova-Adapter needs to get extended for this, since „localost“ seems to be hardcoded as redirect-url)
4. The Keycloak-server will redirect to the app after login succeeded. The App will need to reinitialize the Keycloak-Adapter with the code given in the url - I’m not sure if this will work out of the box.
Does this sound reasonable?
Thanks,
Gregor!
8 years, 1 month
Hosted domain for Google logins
by Steffen Kreutz
Hey Keycloak Devs,
we would like to restrict access to accounts that are managed by our company and therefore need to send the ‚hd‘ to Google’s auth endpoint. I saw that there is already a JIRA issue for that topic under https://issues.jboss.org/browse/KEYCLOAK-5289 <https://issues.jboss.org/browse/KEYCLOAK-5289>. If you agree, I would like to take over it because I already implemented the change in our fork. You can find the changes under https://github.com/yieldlab/keycloak/tree/hosted-domain-parameter-for-goo... <https://github.com/yieldlab/keycloak/tree/hosted-domain-parameter-for-goo...>.
Unfortunately the existing tests fail on my machine and therefore I don’t want to create a PR yet. I think this is because my system’s locale is German. The summary of the failing test is
Failed tests:
SAMLParserTest.testInvalidEndElement
Expected: (an instance of org.keycloak.saml.common.exceptions.ParsingException and exception with message a string containing "The element type \"NameIDFormat\" must be terminated by the matching end-tag \"</NameIDFormat>\".")
but: exception with message a string containing "The element type \"NameIDFormat\" must be terminated by the matching end-tag \"</NameIDFormat>\"." message was "javax.xml.stream.XMLStreamException: ParseError at [row,col]:[31,11]
Message: Elementtyp "NameIDFormat" muss mit dem entsprechenden Endtag "</NameIDFormat>" beendet werden."
This comes because the exception’s message is translated to German but the test matches only the english version. Do you know about this? And what can I do (without changing my system’s locale) to pass the test? I already tried to pass '-Duser.country=DE -Duser.language=de‘ to Maven and the Maven Surefire Plugin but it didn’t help.
Best regards,
Steffen Kreutz
8 years, 1 month
session caching questions
by Matt Domsch (mdomsch)
In our deployments, we have need for the individual nodes in our standalone-ha cluster to be able to be stopped and restarted at any time, without loss of user sessions. We deploy into AWS Elastic Beanstalk, and join the "new" nodes into the existing JGroups cluster of "old" nodes, switch CNAMEs, then shut down the "old" nodes. The default suggested model of using <distributed-cache> for the session and clientSession caches fails in this scenario, as sessions stored only in memory on the "old" nodes are lost. As such, we've switched to <replicated-cache> for most of the caches. Does this make sense? Are most people using Keycloak running >10 nodes per cluster such that replicated cache doesn't make sense for performance reasons? If not, can the example standalone-ha.xml be adjusted to use replicated-cache?
When items are placed into the caches, it seems that they are not put() with a lifetime or expiry time associated with them. This has led us to run into out-of-memory issues as the sizes of these caches grows without bound. We've added expiration times in the XML config to adjust for maximum lifetimes based on the longest session timeouts across all realms. This seems not ideal. It would be better to put() including the current active session timeouts for the realm for the object from which it originates.
We cannot evict items in the sessions and clientSessions caches as they are not persisted to disk. The Offline variants are persisted to disk, so evicting these seem OK. Should this then be an invalidation-cache rather than a replicated-cache?
XML snippet:
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="keycloak" jndi-name="infinispan/Keycloak" statistics-enabled="true">
<replicated-cache name="sessions" mode="SYNC" statistics-enabled="true">
<!-- NOT persisted to the database, so cannot evict within their valid lifetime -->
<!-- max-idle = refresh_token:1 day -->
<expiration max-idle="86700000" interval="300000"/>
</replicated-cache>
<replicated-cache name="clientSessions" mode="SYNC" statistics-enabled="true">
<!-- NOT persisted to the database, so cannot evict within their valid lifetime -->
<!-- max-idle = refresh_token:1 day -->
<expiration max-idle="86700000" interval="300000"/>
</replicated-cache>
<replicated-cache name="authenticationSessions" mode="SYNC" statistics-enabled="true">
<!-- NOT persisted to the database, so cannot evict within their valid lifetime -->
<!-- max-idle = login timeout:1 day -->
<expiration max-idle="86700000" interval="300000"/>
</replicated-cache>
<replicated-cache name="offlineSessions" mode="SYNC" statistics-enabled="true">
<!-- max-idle = refresh_token:30 days -->
<eviction max-entries="10000" strategy="LRU"/>
<expiration max-idle="2592000000" interval="300000"/>
</replicated-cache>
<replicated-cache name="offlineClientSessions" mode="SYNC" statistics-enabled="true">
<eviction max-entries="10000" strategy="LRU"/>
<expiration max-idle="2592000000" interval="300000"/>
</replicated-cache>
Thanks,
Matt
--
Matt Domsch
Executive Director & Senior Distinguished Engineer
Quest | Engineering
Matt.Domsch(a)quest.com<mailto:Matt.Domsch@quest.com>
Mobile 512.981.6486
8 years, 1 month
Testing with mocking libraries?
by Stian Thorgersen
At the moment our testing strategy is only with functional or integration
level tests. Both with the full server up and running and primarily testing
through public APIs.
Now here comes the question should we also allow testing through a mocking
library like Mockito?
In general I'm against mocking libraries. At best you end up with something
that may work, but you're not guaranteed that it actually works. They also
have a very big maintenance cost when any changes are made to the codebase.
However, take a look at https://github.com/keycloak/keycloak/pull/5215 for
example. It is a contribution to add support for the hd param to the Google
login. Not sure how else we could test this without a mocking library.
8 years, 1 month
Any plans to support Web Authentication API?
by Vlastimil Elias
Hi,
it looks like that Web Authentication API [1] is going to be a new
standard widely adopted by browsers to improve web authentication security.
It helps to prevent phishing attacks (as it automatically validates
domain of the login page) and allows to use device's auth hardware (eg
biometrics HW) to login into websites.
Any plans to support it in Keycloak?
More info in Google IO 2018 session and related blogpost [2]
Thanks
Vlastimil
[1] https://www.w3.org/TR/webauthn/
[2] https://developers.google.com/web/updates/2018/05/webauthn
--
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat
8 years, 1 month
PKCE support for Keycloak Adapters (OAuthRequestAuthenticator)
by Thomas Darimont
Hi there,
I was recently playing with the PKCE support in Keycloak (server) which
worked quite well.
However the support for client / adapters seems to be quite limited at the
moment...
I think support for PKCE to all? java adapters could be added quite easily
- I could provide a
PR but I'm currently stuck with finding a generic way to store
the codeVerifier generated for the login redirect for later retrival for
the code2token exchange.
Do you have any recommendations for this?
I created the following JIRA issue (with some comments) to track this:
https://issues.jboss.org/browse/KEYCLOAK-7467
Cheers,
Thomas
8 years, 1 month
