November 2019 - keycloak-dev - Jboss List Archives

by Pedro Igor Silva

Hi, We have started some discussions about a custom policy enforcer at https://github.com/keycloak/keycloak/pull/6448. For those interested in how to programmatically enforce permissions, please look at that PR and discussions that should start to happen here. @Sushil Singh <sushil.singh(a)guavus.com>, If the idea is to expose the PE functionality so that you can programmatically get the same behavior to when requests are processed, I think we can still make it through the `AuthorizationContex` interface. In fact, the code won't change much from what you did so we basically encapsulate the call to the actual policy enforcer. Regards. Pedro Igor

6 years, 4 months

1
0
0 / 0

Re: [keycloak-dev] saml assertion replay

by Ricardo Martin Camarero

Hi, Thanks Hynek, I have filed two feature request jiras: * https://issues.jboss.org/browse/KEYCLOAK-12000: Allow overriding time lifespans on a SAML client * https://issues.jboss.org/browse/KEYCLOAK-12001: Audience support for SAML clients Can I assign them to me? The first one is extremely easy (although I have to wait to have the new console I suppose) and the second is more complicated because it's a new type of protocol mapper (one that receives the SAML builder or similar) but I can work on them when I have time. I suppose there is no hurry for those two JIRAs. About the little PoC I'll make an entry with this in my blog when keycloak 8 is out (for the moment you need to compile it to have the assertion with the signature in the saml subject). Regards! On 11/11/19 9:46 AM, Hynek Mlnarik wrote: > Hi Ricardo, > > On Sat, Nov 9, 2019 at 5:43 PM Ricardo Martin Camarero > <rmartinc(a)redhat.com <mailto:rmartinc@redhat.com>> wrote: > > Hi, > > I have been playing with the assertion replaying that was > introduced a > few weeks ago [1] to do a real example. My PoC consists in a keycloak > SAML adapter that calls a CXF endpoint protected by a > "WssSamlV20Token11" wss4j policy. The wss4j uses opensaml > implementation > so, this way, we test the feature using a different implementation > and > in a real scenario. The summary is: > > Keycloak APP -> SAML login -> recover the signed assertion from the > subject -> call CXF endpoint with the signed assertion -> WS > executed OK > > And it works, but I have seen two snags: > > > That's neat, thanks for doing this! > > 1. The assertion is created with very short periods of validity > (SubjectConfirmationData and Conditions, NotOnOrAfter attribute). The > values are taken from the realm timeouts [1] and the problem is that > those values cannot be overridden for the client like in OIDC. So the > short timeouts for OIDC are not suited for SAML if replay is used. In > normal web SAML this is not important because the > assertion/response is > only checked once at login time. > > > We'd need an option to override assertion lifespan similar to OIDC > client's "Access Token Lifespan" in Advanced, just as you suggest > below. Feel free to add a RFE. > > 2. The other problem is the audience, the audience is set only to the > clientId (same lines in [1], it's the requestIssuer, that later is > set > to the audience in the SAML assertion). When replaying more values > are > needed, one for each final endpoint in which the assertion is > going to > be used. I think SAML audience should also be customizable with > several > values like in OIDC. > > > +1 This would deserve a separate RFE. Doing it via a mapper similar to > OIDC case seems worth investigating. I believe this benefit of being > accompanied a SamlAuthenticationPreprocessor implementation to put it > into a proper place within the SAML assertion - mapper would set the > audience into client session attributes and the preprocessor update > the assertion accordingly. > > Any SAML implementation verifies those restrictions and gives an > error > if any condition is wrong (CXF/opensaml checks the audience with the > endpoint URL and all the time restrictions). I think that those two > points should be improved in order to fully have assertion replay > ready > to be used in the SAML clients. What do you think? Two RFEs? > > Regards! > > [1] https://issues.jboss.org/browse/KEYCLOAK-10757 > [2] > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/o... > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Ricardo Martín Camarero Software Engineer Red Hat <https://www.redhat.com> <https://www.redhat.com>

6 years, 4 months

1
0
0 / 0

Revoking consents and permissions for AccountRestService endpoint

by Bruno Oliveira

Good afternoon, For the applications page, in the new account console, we have the requirement to revoke the consents granted for third-party apps. We already have an endpoint in the AccountRestService[1] for it: ``` @Path("/applications/{clientId}/consent") @DELETE public Response revokeConsent(final @PathParam("clientId") String clientId) { checkAccountApiEnabled(); auth.requireOneOf(AccountRoles.MANAGE_CONSENT); .... } ``` That's exactly what we need, although the REST calls will return HTTP 403 because there's no such role as MANAGE_CONSENT for the `account` client. I'd like to change the endpoint, so that the `account` client would be able to revoke consents. Something like: ``` @Path("/applications/{clientId}/consent") @DELETE public Response revokeConsent(final @PathParam("clientId") String clientId) { checkAccountApiEnabled(); auth.requireOneOf(AccountRoles.MANAGE_CONSENT, AccountRoles.MANAGE_ACCOUNT); ``` Does it make sense? [1] - https://github.com/keycloak/keycloak/blob/041229f9ca393d9bf7a92cabcf1e8b4... -- - abstractj

6 years, 4 months

2
1
0 / 0

saml assertion replay

by Ricardo Martin Camarero

Hi, I have been playing with the assertion replaying that was introduced a few weeks ago [1] to do a real example. My PoC consists in a keycloak SAML adapter that calls a CXF endpoint protected by a "WssSamlV20Token11" wss4j policy. The wss4j uses opensaml implementation so, this way, we test the feature using a different implementation and in a real scenario. The summary is: Keycloak APP -> SAML login -> recover the signed assertion from the subject -> call CXF endpoint with the signed assertion -> WS executed OK And it works, but I have seen two snags: 1. The assertion is created with very short periods of validity (SubjectConfirmationData and Conditions, NotOnOrAfter attribute). The values are taken from the realm timeouts [1] and the problem is that those values cannot be overridden for the client like in OIDC. So the short timeouts for OIDC are not suited for SAML if replay is used. In normal web SAML this is not important because the assertion/response is only checked once at login time. 2. The other problem is the audience, the audience is set only to the clientId (same lines in [1], it's the requestIssuer, that later is set to the audience in the SAML assertion). When replaying more values are needed, one for each final endpoint in which the assertion is going to be used. I think SAML audience should also be customizable with several values like in OIDC. Any SAML implementation verifies those restrictions and gives an error if any condition is wrong (CXF/opensaml checks the audience with the endpoint URL and all the time restrictions). I think that those two points should be improved in order to fully have assertion replay ready to be used in the SAML clients. What do you think? Two RFEs? Regards! [1] https://issues.jboss.org/browse/KEYCLOAK-10757 [2] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/o...

6 years, 4 months

1
0
0 / 0

KEYCLOAK-11885 TypeScript typings are not included in keycloak-nodejs-connect

by Wolfgang Ederer

Hello, the nodejs adapter has a typings file in the repository, but the shipped package does not include the types. This is cause by a missing value in package.json. I have created a pull request here: https://github.com/keycloak/keycloak-nodejs-connect/pull/222 (Travis CI seems to have problems atm) Best Regards Wolfgang Ederer

6 years, 4 months

2
1
0 / 0

Change recaptcha from https://www.google.com to https://www.recaptcha.net

by Stian Thorgersen

We have an open PR that changes reCaptcha to use https://www.recaptcha.net to support reCaptcha where google.com is blocked. https://github.com/keycloak/keycloak/pull/6439

6 years, 4 months

1
0
0 / 0

validating client certificates on user login

by Knüppel, Pascal

Hi I was told to send a mail to the developers mailing list regarding the following issue to get more input from other developers: https://issues.jboss.org/browse/KEYCLOAK-11818 Our problem is that users who login with mutual client-authentication via X509 certificates are still able to login if the certificates are expired or not valid yet. I added a pull request - that is also referenced in the issue - that adds a switch that may be used to validate the notBefore and notAfter timestamps of X509 certificates. From our side we would say that this is actually a security issue that should be fixed very soon. Best regards Pascal Knüppel **************************************************** Veranstaltungsvorschau: Besuchen Sie uns... 11. Jahrestagung E-Akte | 06. + 07.11.2019 | Berlin<https://jahrestagung-eakte.de/> Kongress e-nrw | 07.11.2019 | Düsseldorf/Neuss<https://www.e-nrw.info/> OMNISECURE | 20.-22.01.2020 |Berlin<https://www.omnisecure.berlin/de/> Zukunftskongress Staat & Verwaltung |15.-17.06.2020 | Berlin<https://www.zukunftskongress.info/de/zksv/willkommen>

6 years, 4 months

2
3
0 / 0

import keycloak to Eclipse

by Christian Schuller

Hello, I triedtoimportkeycloak in eclipse, but after followingtheguidesuggested in https://lists.jboss.org/pipermail/keycloak-dev/2019-February/011596.html I still get ~300 Errors. Isthere a recommended Version ofEclipse(I used Eclipse IDE 2019‑09) orsomethingelse I cantrytoimportitsuccessfully? Thanksforyourhelp, Chris

6 years, 4 months

1
0
0 / 0

Versioning - Keycloak Operator

by Bruno Oliveira

Good afternoon, During our stand-up meeting today we discussed the versioning of the new Keycloak Operator. In summary, if the versioning should follow the same scheme as semantic versioning, or follow our continuous delivery model[1]. The "old" Operator is actually on 1.9.4 and the new version should be 2.0.0. But if we use our current versioning scheme, that means a significant bump, for example, 8.0.0. I kind of know the answer :) But the team wanted to ask. [1] - https://www.keycloak.org/2019/04/versioning.html -- - abstractj

6 years, 4 months

8
14
0 / 0

Please Review Updated Getting Started Guide

by Andrew Munro

Folks I have updated this guide to conform to Red Hat standards for modular documentation and made changes based on my testing of the procedures. Note that I could only get the sample app chapter to work in the original version by issuing these commands first: - bin/standalone.sh -b 0.0.0.0 - export WILDFLY_HOME=`pwd`;export JBOSS_HOME=`pwd` However, this did not create the intended set up, so I didn't include it. Should this be added? Here is the PR; https://github.com/keycloak/keycloak-documentation/pull/769 Aslo, the ZIP files that show HTML content for both Keycloak and SSO are in the Jira: https://issues.jboss.org/browse/KEYCLOAK-11876 -- *Andrew Munro* Senior Technical Writer Cell: 978-844-0637 Red Hat <https://www.redhat.com> <https://www.redhat.com>

6 years, 4 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev November 2019