[keycloak-user] Logout with openid-connect is not invalidating the session cookie.
John Bartko
john.bartko at drillinginfo.com
Tue Sep 27 23:41:07 EDT 2016
We also have a handful of non-JS and legacy applications which exhibit the
same behavior. If a user session is logged out in the KC admin web
interface, shouldn't the security proxy stop serving the protected app?
I've listed example security proxy and client configs below if that helps
any.
Security proxy config:
{
"header-names": {
"keycloak-username": "X-UserName"
},
"applications": [
{
"constraints": [
{
"authenticate": true,
"pattern": "/"
}
],
"adapter-config": {
"realm": "dev",
"realm-public-key":
"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4...",
"auth-server-url": "https://auth.dev.example.org/auth",
"resource": "fooapp.example.org",
"public-client": true
},
"base-path": "/"
}
],
"http-port": "8107",
"bind-address": "0.0.0.0",
"send-access-token": true,
"target-url": "http://naked-fooapp.example.org"
}
Corresponding Keycloak client config:
{
"webOrigins": [
"http://fooapp.example.org",
"https://fooapp.example.org"
],
"useTemplateScope": false,
"useTemplateMappers": false,
"useTemplateConfig": false,
"surrogateAuthRequired": false,
"standardFlowEnabled": true,
"serviceAccountsEnabled": false,
"rootUrl": "",
"redirectUris": [
"https://fooapp.example.org/*",
"http://fooapp.example.org/*"
],
"publicClient": true,
"enabled": true,
"directAccessGrantsEnabled": true,
"consentRequired": false,
"clientId": "fooapp.example.org",
"clientAuthenticatorType": "client-secret",
"bearerOnly": false,
"baseUrl": "http://fooapp.example.org/",
"attributes": {
"saml_force_name_id_format": "false",
"saml.server.signature": "false",
"saml.multivalued.roles": "false",
"saml.force.post.binding": "false",
"saml.encrypt": "false",
"saml.client.signature": "false",
"saml.authnstatement": "false",
"saml.assertion.signature": "false"
},
"frontchannelLogout": false,
"fullScopeAllowed": true,
"implicitFlowEnabled": false,
"nodeReRegistrationTimeout": -1,
"notBefore": 0,
"protocol": "openid-connect",
"protocolMappers": [
{
"protocolMapper": "saml-role-list-mapper",
"protocol": "saml",
"name": "role list",
"consentRequired": false,
"config": {
"single": "false",
"attribute.nameformat": "Basic",
"attribute.name": "Role"
}
},
{
"protocolMapper": "oidc-usermodel-property-mapper",
"protocol": "openid-connect",
"name": "given name",
"consentText": "${givenName}",
"consentRequired": true,
"config": {
"user.attribute": "firstName",
"jsonType.label": "String",
"id.token.claim": "true",
"claim.name": "given_name",
"access.token.claim": "true"
}
},
{
"protocolMapper": "oidc-usermodel-property-mapper",
"protocol": "openid-connect",
"name": "username",
"consentText": "${username}",
"consentRequired": true,
"config": {
"user.attribute": "username",
"jsonType.label": "String",
"id.token.claim": "true",
"claim.name": "preferred_username",
"access.token.claim": "true"
}
},
{
"protocolMapper": "oidc-usermodel-property-mapper",
"protocol": "openid-connect",
"name": "family name",
"consentText": "${familyName}",
"consentRequired": true,
"config": {
"user.attribute": "lastName",
"jsonType.label": "String",
"id.token.claim": "true",
"claim.name": "family_name",
"access.token.claim": "true"
}
},
{
"protocolMapper": "oidc-usermodel-property-mapper",
"protocol": "openid-connect",
"name": "email",
"consentText": "${email}",
"consentRequired": true,
"config": {
"user.attribute": "email",
"jsonType.label": "String",
"id.token.claim": "true",
"claim.name": "email",
"access.token.claim": "true"
}
},
{
"protocolMapper": "oidc-full-name-mapper",
"protocol": "openid-connect",
"name": "full name",
"consentText": "${fullName}",
"consentRequired": true,
"config": {
"id.token.claim": "true",
"access.token.claim": "true"
}
}
]
}
On Mon, Sep 26, 2016 at 9:53 AM, Marek Posolda <mposolda at redhat.com> wrote:
> It's strongly recommended to use our keycloak.js adapter. It doesn't use
> cookies to maintain state. See our examples for it in the example
> distribution.
>
> If you handle things manually, you need to care about various things (like
> refreshes etc) and for logout, you of course need to care of manually
> removing all the OAuth related state from your application and possibly
> remove cookies (if your application is using them).
>
> Marek
>
>
>
> On 22/09/16 02:01, Sean Schade wrote:
>
> Do I need to use the Keycloak JS adapter in our Angular app in order to
> get logout to work correctly? I thought we would be fine with just the
> openid-connect logout url. It looks like the adapter clears the token in
> the browser.
>
> https://github.com/keycloak/keycloak/tree/master/adapters/
> oidc/js/src/main/resources
>
>
> On Wed, Sep 21, 2016 at 2:08 PM, Sean Schade <sean.schade at drillinginfo.com
> > wrote:
>
>> Thanks Scott for replying. We don't use an adapter. We have an Angular
>> app that makes HTTP calls to backend services. All of our services are
>> behind a Keycloak Security Proxy.
>>
>> We are migrating away from Oracle OAM to Keycloak, and with Oracle
>> navigating to the logout link was sufficient. I assumed the same would be
>> for Keycloak.
>>
>> I initially thought this might be the bug: https://issues.jboss.org/
>> browse/KEYCLOAK-3311
>>
>> However, after looking at the logs in Keycloak when I click the Logout
>> button in our app I see the following errors.
>>
>> 18:55:10,630 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
>> task-11) RESTEASY002130: Failed to parse request.: javax.ws.rs.core.
>> UriBuilderException: RESTEASY003330: Failed to create URI: null
>>
>>
>> 1. Caused by: javax.ws.rs.core.UriBuilderException: RESTEASY003280:
>> empty host name
>> 2. at org.jboss.resteasy.specimpl.ResteasyUriBuilder
>> .buildString(ResteasyUriBuilder.java:540)
>> 3. at org.jboss.resteasy.specimpl.ResteasyUriBuilder
>> .buildFromValues(ResteasyUriBuilder.java:743)
>>
>>
>> Perhaps it is a combination of the Keycloak Security Proxy and some
>> misconfiguration? I'm not really sure at this moment.
>>
>> Is my assumption correct that we do not need an adapter for oidc logout?
>>
>> On Wed, Sep 21, 2016 at 1:29 PM, Scott Rossillo <srossillo at smartling.com>
>> wrote:
>>
>>> Which adapter are you using?
>>>
>>> Scott Rossillo
>>> Smartling | Senior Software Engineer
>>> srossillo at smartling.com
>>>
>>> On Sep 21, 2016, at 2:03 PM, Sean Schade <sean.schade at drillinginfo.com>
>>> wrote:
>>>
>>> We are having an issue where our browser application will initiate a
>>> logout, but after redirecting back to the application the user is not taken
>>> to the login screen. It appears the user is still logged in, and can fully
>>> access the application. I can see the session removed in Keycloak Admin UI.
>>> However, it appears the cookie never gets invalidated. Here is the redirect
>>> URL we use. Are we missing some configuration step in the client? I have
>>> standard flow, implicit flow, and direct access grants enabled. Valid
>>> redirect URIs, Base URL, and web origins are all configured in the client.
>>> Admin URL is not set as we are relying only on browser logout.
>>>
>>> https://auth.dev.drillinginfo.com/auth/realms/dev/protocol/openid-connect/logout?redirect_uri=https%3A%2F%2Fapp.dev.drillinginfo.com/gallery/
>>>
>>> _______________________________________________ keycloak-user mailing
>>> list keycloak-user at lists.jboss.org https://lists.jboss.org/mailma
>>> n/listinfo/keycloak-user
>>>
>>> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160927/2174aa22/attachment-0001.html
More information about the keycloak-user
mailing list