Keycloak Broker - OIDC client with SAML2 identity provider
by Jimena Garbarino
Hi,
Is it possible to configure an OpenID connect client for authentication,
using Keycloak as a broker to a SAML2 identity provider (ADFS)?
I am trying to do so, and after ADFS successful authentication, Keycloak
always displays the login form.
Thanks,
2017-12-04 19:16:08,150 DEBUG
[org.keycloak.services.resources.IdentityBrokerService] (default task-31)
Authorization code is valid.
2017-12-04 19:16:08,152 DEBUG [org.keycloak.saml.BaseSAML2BindingBuilder]
(default task-31) saml document: <samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion" AssertionConsumerServiceURL="
https://localhost:8061/auth/realms/master/broker/adfs-idp-alias/endpoint"
Destination="https://adfs/adfs/ls/" ForceAuthn="false"
ID="ID_ad013a22-7c3b-4aa9-a8f9-3fcf6a7cb96b" IsPassive="false"
IssueInstant="2017-12-04T19:16:08.151Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Version="2.0"><saml:Issuer
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://localhost:8061/auth/realms/master</saml:Issuer><samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>
2017-12-04 19:16:08,153 DEBUG
[org.keycloak.services.resources.IdentityBrokerService] (default task-31)
Identity provider [org.keycloak.broker.saml.SAMLIdentityProvider@678796c4]
is going to send a request
[org.jboss.resteasy.specimpl.BuiltResponse@5976b246].
2017-12-04 19:16:08,153 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-31)
JtaTransactionWrapper commit
2017-12-04 19:16:08,153 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-31)
JtaTransactionWrapper end
2017-12-04 19:16:08,347 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-64) new
JtaTransactionWrapper
2017-12-04 19:16:08,348 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-64) was
existing? false
2017-12-04 19:16:08,349 DEBUG [org.keycloak.saml.SAMLRequestParser]
(default task-64) SAML Redirect Binding
2017-12-04 19:16:08,349 DEBUG [org.keycloak.saml.SAMLRequestParser]
(default task-64) <samlp:Response
ID="_ac706804-f304-4153-88e0-07aee06dd4e6" Version="2.0"
IssueInstant="2017-12-04T19:16:08.360Z" Destination="
https://localhost:8061/auth/realms/master/broker/adfs-idp-alias/endpoint"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
InResponseTo="ID_ad013a22-7c3b-4aa9-a8f9-3fcf6a7cb96b"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
http://adfs/adfs/services/trust</Issuer><samlp:Status><samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Responder"
/></samlp:Status></samlp:Response>
2017-12-04 19:16:08,350 DEBUG
[org.keycloak.services.resources.IdentityBrokerService] (default task-64)
Got authorization code from client [oidc-client].
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.services.resources.IdentityBrokerService] (default task-64)
Authorization code is valid.
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.AuthenticationProcessor] (default task-64)
AUTHENTICATE
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.AuthenticationProcessor] (default task-64)
AUTHENTICATE ONLY
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
processFlow
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
check execution: auth-cookie requirement: ALTERNATIVE
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
execution is processed
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
check execution: auth-spnego requirement: DISABLED
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
execution is processed
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
check execution: identity-provider-redirector requirement: ALTERNATIVE
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
execution is processed
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
check execution: null requirement: ALTERNATIVE
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
execution is flow
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
processFlow
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
check execution: auth-username-password-form requirement: REQUIRED
2017-12-04 19:16:08,351 DEBUG
[org.keycloak.authentication.DefaultAuthenticationFlow] (default task-64)
authenticator: auth-username-password-form
8 years, 1 month
Keycloak theme deployer s2i
by Anton
Hello
We are trying to figure out how to deploy a theme into a keycloak image
running on OpenShift.
Are there any s2i images for keycloak?
Thanks
8 years, 1 month
OIDC claims are not mapped on first login
by Rens Verhage
I have configured an OIDC identity provider and added a few attribute Attribute Importer mappers, such as (claim -> attribute):
preferred_username -> username
email -> email
However, on first login, Keycloak asks me to supply missing user information, including username and e-mail. Username is pre-filled with the sub-claim, everything else is empty.
Did I miss some additional config? I also have a hardcode role which is working fine. Maybe I don’t have the properties right, but I can’t find a list of Keycloak user properties and how to access them through attribute mappers.
Rens
8 years, 1 month
Question for role-based authorization scenario with keycloak
by Fischer Oliver (INST/ECS4)
Hi Keycloak-Community,
I need some help setting up a role based authorization with keycloak. Suppose you have authorization data model like this:
{
"roles": {
"publisher": [
{
"resource": "/telemetry",
"activities": [ "WRITE" ]
}
],
"consumer": [
{
"resource": "/telemetry",
"activities": [ "READ" ]
}
]
},
"users": {
"client-sender": {
"password": "secret",
"authorities": [ "publisher" ]
},
"client-receiver": {
"password": "secret",
"authorities": [ "consumer" ]
}
}
}
Users (service account clients) and roles (defined for client called my-application) can be easily integrated into keycloak. An example access token should look like this:
{
"jti": "9290a241-45ad-4c14-b6e3-fdf906c7c102",
"exp": 1511887924,
"clientId": "client-sender",
...
"resource_access": {
"my-application": {
"roles": [
"publisher"
]
}
}
}
In keycloak, when enabling "Fine-grained authorization support" for the application (client called my-application), resources (like "/telemetry") and permissions (like "WRITE") can be defined.
The question is:
How do I get the connection between resources/permissions and the roles?
Or to be more precise, how to get those resources/permissions into the access token?
Thanks a lot in advance,
Oliver Fischer
8 years, 1 month
cdi @inject KeycloakSecurityContext
by Matthew Broadhead
is there any mechanism to @Inject KeycloakSecurityContext into an
@ApplicationScoped CDI? i am trying to use @Produces but it is quite tricky
8 years, 1 month
Adding custom user claims after login
by Paolo Tedesco
Hi all,
I would need to add dynamically some custom client-specific claims to a user's token after authentication.
The basic idea is that I would need to call an external application, asking for the custom claims for the authenticated user for the target client.
If I've understood correctly, I cannot do this with mappers, and I could not find a custom SPI type that fits this purpose.
Is there a way to do this with Keycloak?
Thanks,
Paolo
8 years, 1 month
Re: [keycloak-user] Impersonate user feature stop working after 3.2.0.Final
by Diego Diez
After clicking the button I can see the account of the impersonated user,
but the SSO doesn't seem to work.
When I go to another app, the login form is prompt again instead of a new
redirect with the user logged in to the app automatically.
That's the issue I meant in the first place. Sorry for the lack of details.
PD: the app I used to reproduce the problem was secured using the spring
security adapter for spring boot
El 29 nov. 2017 9:33 p. m., "Stian Thorgersen" <sthorger(a)redhat.com>
escribió:
Oh and we do have tests as well for it ;)
On 29 November 2017 at 21:33, Stian Thorgersen <sthorger(a)redhat.com> wrote:
> Just tried it here and works just fine for me.
>
> On 29 November 2017 at 18:24, Diego Diez <diegodiez.ddr(a)gmail.com> wrote:
>
>> Hi Keycloak Community,
>>
>>
>> After successfully upgrade our servers from keycloak 2.5.4.Final to
>> 3.4.0.Final, we have notice that the impersonation feature isn't
>> working anymore.
>>
>> We have tested other versions with a vanilla install and the first
>> version with this problem is 3.2.0.Final.
>>
>> Are you experiencing this problem? Impersonation is a quite useful
>> feature to us, so any workaround until next release would be great.
>>
>>
>> Regards,
>>
>> Diego Díez
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
8 years, 1 month
Authentication broken after 3.0.0 -> 3.4.0 upgrade
by Dmitry Korchemkin
Hello,
I'm looking into upgrading from 3.0.0.Final to 3.4.0.Final and my REST
endpoints work fine, tokens are issued, validated, etc, no regression
there. Login functionality, however, is broken due to missing
AUTH_SESSION_ID cookie.
Here's how my auth request looks like:
http://gateway-my-app.com/auth/realms/myRealm/login-
actions/authenticate?code=ys5CKFbsTfM1ab2L6cZ3xqx0lTCwv3
gJvoEcdsbIoSM.c5a89496-8b6c-4ca2-a188-b7a075d8957b&
execution=50a77434-5243-44df-84c4-cc3ff4be2ac6&kc_locale=en
Cookie:69d2fc8ce07e4c342f8d612131c6fdd7=2c5f013d0341025df301bde47ce2c80a
Host:http://gateway-my-app.com
Origin:http://gateway-my-app.com
Referer:
http://gateway-my-app.com/api/v1/identity-provider/auth/
realms/myRealm/protocol/openid-connect/auth?response_
type=token&client_id=myClient&redirect_uri=http%3A%2F%2Fmy-
app-interface.com%2Floginpages%2Fclose.html&nonce=1150678440871.8186&kc_
locale=en-US
Gateway doesn't do much in terms of cookies replacement, it only ensures
that things like host and origin are correct.
I run it on openshift based on keycloak-ha-postgres dockerfile. Login pages
for microservices are rendered as iframes.
Might there be something specific to OpenShift (maybe its router?) or
rendering login page in iframe that might prevent AUTH_SESSION_ID cookie
from appearing?
Best regards,
Dmitry
8 years, 1 month
