Re: [keycloak-dev] Testing with mocking libraries?
by Marek Posolda
Dne 1.6.2018 v 14:48 Bill Burke napsal(a):
> On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
>> For IDP, I am not sure how would Mocked IDP help? We already have lots of
>> test coverage for Identity brokering for OIDC and SAML. The social providers
>> usually implements OAuth/OIDC and there are just small differences between
>> them. But those small differences and the fact that social providers are out
>> of our control, is exactly the reason why we need to test with real
>> providers instead of mocks IMO.
>>
> IDP mocks are not a replacement for real testing. Just something that
> would run in public CI, that way at least there's something to catch
> issues like when/if brokering gets refactored again.
AFAIK the longer-term plan is to run social tests on every PR, to catch
regressions by testing with real social providers. So maybe it's better
to rather wait until we have that rather then introduce mocks now?
Also anyone from community should be able to run social tests based on
our README. The important is, that someone could run it just for single
provider, which he is interested in (EG. Google for this PR) and is not
required to create the account+application in all social providers,
which we support. But I hope the social tests already support this now.
Marek
>
> Bill
5 years, 10 months
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
5 years, 10 months
Re: [keycloak-dev] Improve "Logout all" for the realm?
by Hynek Mlnarik
On Wed, Jun 6, 2018 at 8:48 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 06/06/18 08:28, Stian Thorgersen wrote:
> >
> >
> > On 5 June 2018 at 22:13, Marek Posolda <mposolda(a)redhat.com
> > <mailto:mposolda@redhat.com>> wrote:
> >
> > Hi,
> >
> > when you click on tab "Sessions", you can see the screen with the:
> > - counts of Active Sessions
> > - counts of Offline Sessions
> > - Button "Logout All"
> >
> > See the screenshot how the screen currently looks like:
> > https://pasteboard.co/HowNZ2I.png <https://pasteboard.co/HowNZ2I.png
> >
> >
> > We have the JIRA https://issues.jboss.org/browse/KEYCLOAK-7055
> > <https://issues.jboss.org/browse/KEYCLOAK-7055> and the
> > PR with the discussion
> > https://github.com/keycloak/keycloak/pull/5126
> > <https://github.com/keycloak/keycloak/pull/5126> .
> > In shortcut, JIRA and PR points few issues:
> > 1) There is no way to logout all active sessions only (Keep the
> > offline
> > sessions)
> >
> > 2) There is no way to logout all offline sessions only (Keep the
> > active
> > sessions)
> >
> > 3) When you click on the button, there is no confirmation dialog. It
> > seems that "Logout all" is quite an important step and confirmation
> > should be there.
> >
> > 4) When you click on the button, it will do something between. All
> > active sessions are cleared from infinispan, but offline sessions are
> > NOT cleared. There is just realm notBefore policy updated, which
> > indirectly invalidates the offline sessions, but they are still
> > kept in
> > infinispan and DB, which itself is a bug IMO.
> >
> > So how to address all the issues? I can see something like this:
> > - Instead of 1 button, have 3 buttons (Logout all active sessions,
> > Logout all offline sessions, Logout all)
> >
> >
> > Sounds good, but might look a bit messy with those long labels and 3
> > buttons. Do we need 3 buttons? Or is "Logout active" and "Logout
> > offline" sufficient? Do we have a better term for non-offline than
> active?
> The thing is, that with "Logout active" and "Logout offline", you can't
> update notBefore policy. If you update it, you always effectively
> invalidate both kind of sessions.
>
> I was also thinking about keep the single button, but once confirmation
> dialog is displayed, you will have 3 checkboxes in it (push not-before,
> logout active, logout offline) and all checked by default. When you
> uncheck "logout active" or "logout offline", it will also automatically
> uncheck "push not-before" . In other words, "push not-before" always
> require both other checkboxes checked due the reason above.
>
> Is it better regarding usability? I am not sure as admin won't see that
> "Logout all" has more options until he clicks on it and dialog is
> displayed?
>
I'd prefer this suggestion with checkboxes.
> >
> >
> > - All the buttons will display confirmation dialog
> >
> >
> > +1
> >
> > - The "Logout all" will also update notBefore policy like it's
> > done now.
> > It will clear all the "Active" and "Offline" sessions from
> > infinispan.
> > This will be displayed in the confirmation dialog. So confirmation
> > for
> > "Logout all" will be like: "Do you want to logout all active sessions
> > and offline sessions and update realm notBefore policy?" The other 2
> > buttons won't update not-before policy (we can't do that unless we
> > have
> > separate not-before for active sessions and for offline sessions,
> > but I
> > vote to not do that considering the required complexity of this).
>
+1 for not separating not-before for offline and active.
> >
> >
> > Should it also clear sessions from the DB?
> Yes
> >
> >
> > - The message for "Logout all" will be sent to all the clients with
> > adminUrl (which is already done).
> >
> > One related issue is, that currently we don't have a way to notify
> > client applications that offline sessions were invalidated. I was
> > thinking if we could have a way to register some listener for various
> > adapter events (Logout all, logout all active/offline sessions,
> > logout
> > single active/offline session)? Client application can listen to the
> > events and do something (EG. remove saved offline token from it's
> DB).
> >
> >
> > I'm not to keen on more bespoke logout protocols. Have we studied the
> > OIDC backchannel/frontchannel specs yet? Is there a way to do this in
> > a standard way?
> Ok, true. I've looked at the specs some time ago, we already partially
> implement something from them.
>
> I remember front-channel logout specs contains some interesting usage of
> iframes (You will display single HTML page with the iframes, where each
> iframe contains the URL to logout single client). Is it pretty
> interesting stuff and seems to be much less error-prone than
> chain-of-redirects approach, which SAML Front-channel logout uses. I've
> proposed to support iframes for SAML Front-channel logout too some time
> ago on this list. I think Bill and Hynek liked it. We just need to
> implement those things :)
>
Yup, it would make things (a) parallel - hence faster, (b) less error-prone
since redirect back to Keycloak is currently needed in SAML frontchannel
logout and if some application fails to do that, the subsequent
applications are not logged out. SAML frontchannel logout via iframes was
almost implemented during cross-dc work but then abandoned because of time.
The JIRA for that is [1] and contains the link to initial implementation.
Just note that the implementation did not consider OIDC frontchannel logout
draft and needs to be adjusted accordingly.
--Hynek
[1] https://issues.jboss.org/browse/KEYCLOAK-5449
5 years, 10 months
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
5 years, 10 months
Improve "Logout all" for the realm?
by Marek Posolda
Hi,
when you click on tab "Sessions", you can see the screen with the:
- counts of Active Sessions
- counts of Offline Sessions
- Button "Logout All"
See the screenshot how the screen currently looks like:
https://pasteboard.co/HowNZ2I.png
We have the JIRA https://issues.jboss.org/browse/KEYCLOAK-7055 and the
PR with the discussion https://github.com/keycloak/keycloak/pull/5126 .
In shortcut, JIRA and PR points few issues:
1) There is no way to logout all active sessions only (Keep the offline
sessions)
2) There is no way to logout all offline sessions only (Keep the active
sessions)
3) When you click on the button, there is no confirmation dialog. It
seems that "Logout all" is quite an important step and confirmation
should be there.
4) When you click on the button, it will do something between. All
active sessions are cleared from infinispan, but offline sessions are
NOT cleared. There is just realm notBefore policy updated, which
indirectly invalidates the offline sessions, but they are still kept in
infinispan and DB, which itself is a bug IMO.
So how to address all the issues? I can see something like this:
- Instead of 1 button, have 3 buttons (Logout all active sessions,
Logout all offline sessions, Logout all)
- All the buttons will display confirmation dialog
- The "Logout all" will also update notBefore policy like it's done now.
It will clear all the "Active" and "Offline" sessions from infinispan.
This will be displayed in the confirmation dialog. So confirmation for
"Logout all" will be like: "Do you want to logout all active sessions
and offline sessions and update realm notBefore policy?" The other 2
buttons won't update not-before policy (we can't do that unless we have
separate not-before for active sessions and for offline sessions, but I
vote to not do that considering the required complexity of this).
- The message for "Logout all" will be sent to all the clients with
adminUrl (which is already done).
One related issue is, that currently we don't have a way to notify
client applications that offline sessions were invalidated. I was
thinking if we could have a way to register some listener for various
adapter events (Logout all, logout all active/offline sessions, logout
single active/offline session)? Client application can listen to the
events and do something (EG. remove saved offline token from it's DB).
WDYT?
Marek
5 years, 10 months
Re: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing
by 乗松隆志 / NORIMATSU，TAKASHI
Hello,
Therefore, I would like to contribute this SPI.
As you said, I will issue a separate PR for it.
I would be happy if you and keycloak core contributors give some advice when my encountering problems.
Best regards,
Takashi Norimatsu
Hitachi Ltd.,
----------
From: Stian Thorgersen <sthorger(a)redhat.com>
Sent: Wednesday, May 30, 2018 4:35 PM
To: 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com>
Cc: keycloak-dev(a)lists.jboss.org
Subject: [!]Re: Re: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing
On 30 May 2018 at 07:49, 乗松隆志 / NORIMATSU，TAKASHI <mailto:takashi.norimatsu.ws@hitachi.com> wrote:
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.
On the server-side that is easy. On the adapter side that would probably require adding a property to keycloak.json to set the algorithm. In either case it should probably default to RSA for existing realms at least, but we could consider setting it to ES256 for new realms.
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?
We don't currently have any plans on implementing this SPI and where holding off on it until we started work on adding ES256. The ideal here may be that someone from the core team work on the SPI and refactoring of RSA provider, then you can update the PR for ES256. Unless you feel that you may be able to contribute that as well? If so I would prefer a separate PR for the SPI and refactoring.
Best regards,
Takashi Norimatsu
Hitachi Ltd.,
From: Stian Thorgersen <mailto:sthorger@redhat.com>
Sent: Tuesday, May 29, 2018 4:40 PM
To: 乗松隆志 / NORIMATSU，TAKASHI <mailto:takashi.norimatsu.ws@hitachi.com>
Cc: mailto:keycloak-dev@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: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:mailto:keycloak-dev@lists.jboss.org
https://clicktime.symantec.com/a/1/LBlgE63-JxZCbiegUCPqUTy7Oeq2A8tzZfOiWv...
5 years, 10 months
Keycloak Feature development: Integrate ext. IdP to keycloak (like Google, facebook)
by Ansari, Hasebullah
Hello all,
My name is Haseb Ansari and by profession I’m an IT Specialist / Java Developer working for a German based company called Syntlogo GmbH. For the last one a half years I’ve been playing with Keycloak right from version 1.9.8.Final to 4.0.0.Beta1. For one of our (company’s) usecase, I’ve already integrated an external IdP(IdP really famous in Germany but not globally) through Keycloak SPI. With my experience so far, I’d now like to make a small contribution to Keycloak, an integration of an external identity provider i.e. ‘Login with Amazon’. Before proceeding further, I’d like to have suggestion from you guys whether I’ll have to consider some points like ‘do we need permission from Amazon?’ or any other data protection stuff?
Let me know about any detailed points I’ll have to consider while implementing
Cheers,
__________________________________________________________________________________________________________________________
Besuchen Sie LOGIN MASTER<https://login-master.com/> – Die Lösung für die Benutzerverwaltung für das Web.
__________________________________________________________________________________________________________________________
Hasebullah A Ansari
Master of Engineering in IT, Heidelberg
IT Specialist / Java Entwickler
Syntlogo GmbH
Mercedesstraße 1
D-71063 Sindelfingen
Email: hasebullah.ansari(a)syntlogo.de<mailto:hasebullah.ansari@syntlogo.de>
Mobile: +49 151 168 39585
Website: www.syntlogo.de<http://www.syntlogo.de/>
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfänger sein, so bitten wir Sie höflichst, diesen Umstand
unverzüglich dem Absender mitzuteilen und die Nachricht zu löschen. Jede nicht genehmigte Weiterverbreitung oder Vervielfältigung
ist nicht gestattet. Da wir Echtheit und Vollständigkeit des Nachrichteninhalts nicht garantieren können, sind die vorstehenden
Ausführungen rechtlich nicht bindend. Eine Haftung hierfür wird daher ausgeschlossen.
This message is confidential. If you are not the intended recipient, we kindly ask you to inform the sender and delete the information.
Any unauthorised dissemination or copying hereof is prohibited. As we cannot guarantee the genuineness or completeness of the information
contained in this message, the statements set forth above are not legally binding. Accordingly, we cannot accept liability therefore.
Stuttgart HRB 245317, Geschäftsführer Dr. G. Baruzzi, USt-ID: DE 219566705
__________________________________________________________________________________________________________________________
5 years, 10 months
