Re: [keycloak-user] Behind a reverse proxy using context path
by Andy Yar
Oh, I am sorry. I have overlooked the notice about the need of changing the
root context manually in docs. The deployed Keycloak seems to be working
smoothly now.
I shall create issues for both problems I encountered.
Thanks a lot for your support.
On Wed, Jan 13, 2016 at 7:24 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> The clients are created with the initial context path. If you change the
> context path you currently have to manually go to the admin console and
> change it first. Both issues you've encountered are not ideal and you can
> create jira issues for those.
>
> On 13 January 2016 at 17:18, Andy Yar <andyyar66(a)gmail.com> wrote:
>
>> OK, I forgot to mention I used to have the Keycloak set to run on the
>> root context. So I removed the root context mapping set the
>> "standalone.xml" to "sso" and customized the nginx settings accordingly.
>>
>> Now I am able to enter the admin/, although redirecting to the login form
>> for the master realm ends with an error - "Invalid parameter:
>> redirect_uri". Apparently the context path "sso/" is ignored by a security
>> pattern.
>>
>> Log dump:
>> 2016-01-13 17:06:21,858 DEBUG
>> [org.keycloak.protocol.oidc.utils.RedirectUtils] (default task-15)
>> replacing relative valid redirect with:
>> https://domain.foo/auth/admin/master/console/*
>> 2016-01-13 17:06:21,876 WARN [org.keycloak.events] (default task-15)
>> type=LOGIN_ERROR, realmId=master, clientId=security-admin-console,
>> userId=null, ipAddress=x.x.x.x, error=invalid_redirect_uri,
>> response_type=code, redirect_uri=
>> https://domain.foo/sso/admin/master/console/, response_mode=fragment
>>
>> Thanks
>>
>>
>> On Wed, Jan 13, 2016 at 2:44 PM, Stian Thorgersen <sthorger(a)redhat.com>
>> wrote:
>>
>>> Looks like it may be a bug caused by context-path on the server being
>>> different than context-path on the reverse proxy.
>>>
>>> Try setting web-context for urn:jboss:domain:keycloak-server:1.1 in
>>> standalone.xml to "sso". If that works please create a bug.
>>>
>>> On 13 January 2016 at 14:27, Andy Yar <andyyar66(a)gmail.com> wrote:
>>>
>>>> Hello,
>>>> I'm stuck with Keycloak 1.7.0 Final on WildFly 9 behind a reverse proxy
>>>> (nginx). The WildFly is configured for proxying according to the Keycloak
>>>> guide and the proxy sends the needed custom HTTP headers.
>>>>
>>>> I have a public SSL secured domain and nginx proxying requests to
>>>> internal WildFly server. I would like to use URL:
>>>> https://domain.foo/sso/ to access the Keycloak (internal WildFly). I
>>>> guess the context path (sso/) is important here.
>>>>
>>>> Accessing the address I can reach the Keycloak default welcome page.
>>>> However, a GET https://domain.foo/sso/admin results in 302 to Location:
>>>> https://domain.foo/admin/master/console/. Obviously this redirect
>>>> fails because its Location misses the needed context path (sso/). Adding
>>>> the context path to a request manually results in a 200 but following
>>>> resources fail to download because of the missing context path part of URL.
>>>>
>>>> Is my configuration wrong? Is there a way how the original base URL can
>>>> be set? Is it even possible to have it behind a reverse proxy not running
>>>> at root context? Is the origin detection broken?
>>>>
>>>> Thanks in advance
>>>> Andy
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>
9 years
Logging when in Impersonate mode
by Rajees Patel
Hi,
For auditing reasons we have a requirement that all user actions are
logged.
If user X is impersonating user Y, is it possible that this be logged
somewhere? i.e
13 Jan 2016 16:47:56 INFO User X is impersonating User Y
We are concerned that user X may impersonate user Y and perform some
malicious actions, and we will have no idea that this happened.
Regards
Raj
Rajees Patel
Product Architect
Invenco Group Limited
O: +64 9 905 5673
Rajees.Patel(a)invenco.com <mailto:Rajees.Patel@invenco.com>
www.invenco.com <http://www.invenco.com>
Disclaimer: This email is confidential and may be legally privileged.
If you are not the intended recipient you must not use any of the
information in it and must delete the email immediately.
9 years
retrieving group membership info from LDAP/AD
by Mahantesh Prasad Katti
Hi All,
In our application, we integrate with Microsoft AD for authenticating users. As part of the authentication result, we also fetch group information for the user authenticated. We also have a pre-defined group-role mapping defined in the application server [This is a JEE configuration file]. This helps decide whether a particular user based on the role he belongs to can access a resource or not. I read another thread "Apply group membership filter on ldap login <http://lists.jboss.org/pipermail/keycloak-user/2015-December/003982.html> " on similar lines. Couple of clarifications.
1. Based on what I read there is no feature to get roles and map them to specific roles in keycloak and would be available in a future release. I just wanted to understand if my reading of this is on the right lines. Also, wanted to know if there's a workaround for this in the short term.
2. Also does keycloak provide fine grained access control on the lines of apache shiro?
Thanks
Prasad
9 years
keycloak & tomcat on same host/domain + nginx reverse proxy server
by Adrian Matei
Can anyone help me with a configuration of keycloak (port 8180) and tomcat
(port 8080) running on the same host/domain having nginx as reverse proxy
server in front of it (new to nginx).
Accessed on individual ports they run perfectly but when going over nginx,
tomcat address (localhost) works but keycloak (localhost/auth) won't.
Here's my nginx configuration:
user www-data;
worker_processes 4;
pid /run/nginx.pid;
events {
worker_connections 1024;
# multi_accept on;
}
http {
server_tokens off; #hides nginx version and OS running on
include /etc/nginx/mime.types;
upstream tomcat_server {
server localhost:8080;
}
upstream keycloak_server {
server localhost:8180;
}
server {
listen 80;
server_name localhost;
location / {
try_files $uri $uri/index.hml /maintenance.html @tomcat;
}
location @tomcat {
proxy_pass http://tomcat_server;
proxy_set_header Host $host;
}
location /auth/ {
proxy_pass http://keycloak_server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
Thanks,
Adrian
9 years
Behind a reverse proxy using context path
by Andy Yar
Hello,
I'm stuck with Keycloak 1.7.0 Final on WildFly 9 behind a reverse proxy
(nginx). The WildFly is configured for proxying according to the Keycloak
guide and the proxy sends the needed custom HTTP headers.
I have a public SSL secured domain and nginx proxying requests to internal
WildFly server. I would like to use URL: https://domain.foo/sso/ to access
the Keycloak (internal WildFly). I guess the context path (sso/) is
important here.
Accessing the address I can reach the Keycloak default welcome page.
However, a GET https://domain.foo/sso/admin results in 302 to Location:
https://domain.foo/admin/master/console/. Obviously this redirect fails
because its Location misses the needed context path (sso/). Adding the
context path to a request manually results in a 200 but following resources
fail to download because of the missing context path part of URL.
Is my configuration wrong? Is there a way how the original base URL can be
set? Is it even possible to have it behind a reverse proxy not running at
root context? Is the origin detection broken?
Thanks in advance
Andy
9 years
Adapter 1.3.1 on EAP 6.3.2
by Mitja Strojanšek
We have REST services on EAP 6.3.2 with adapter 1.3.1 and gateway server
WF 8.2 with 1.3.1 server. This configuration doesn't work. Our test case
works on WF 8.2 server with adapter 1.3.1.
Does anybody has idea, why it shouldn't work also with EAP 6.3.2? Are
there any incompatibilities?
--
*Mitja*
9 years
There is no assertion error
by Mai Zi
Hi, there,
We take keycloak as a SP to talk to a SAML2.0 IDP . When we login into that idp, we get an internal server error. We check the log and find this lines:
Caused by: org.keycloak.saml.common.exceptions.ProcessingException: No assertion from response. at org.keycloak.saml.processing.core.saml.v2.util.AssertionUtil.getAssertion(AssertionUtil.java:529)
at org.keycloak.broker.saml.SAMLEndpoint$Binding.handleLoginResponse(SAMLEndpoint.java:268)
That is, No assertion from response.
The idp is ADFS system.
We are not sure where the root cause is from. If it is idp 's problem, what evidence can we show to IDP team ?
Thanks alotMai
9 years
keycloak-servlet-filter-adapter and bearer-only
by Ramon Rockx
Hi all,
Maybe someone can help me out with the following;
I'm trying to secure my Jax-RS services with Keycloak 1.7.0.Final. I
configured for this a client in Keycloak with access type 'bearer-only'.
Since I am using GlassFish 3.1 (no adapter available), I use the
'keycloak-servlet-filter-adapter'.
When accessing one of the Jax-RS services with a valid token, GlassFish
will throw an exception (with no relevant info in it). I debugged it, and
found out that the HttpServletRequestWrapper, which is returned by the
servlet filter, has no account property in it (see also
FilterSessionStore.buildWrapper(HttpSession,
KeycloakAccount)). And when GlassFish will try to access, for example the
wrapper's principal, this will cause a NPE.
It seems that FilterRequestAuthenticator.completeBearerAuthentication(KeycloakPrincipal<RefreshableKeycloakSecurityContext>,
String) does not store the account in the tokenStore.
Should I use this feature differently? Or is access type 'bearer-only'
simply not supported by the servlet filter?
Thanks!
Ramon Rockx
9 years
KeyCloak Use Cases
by Sonia Marginean
Hello,
My org is researching different open source solutions for IDP, SSO and Inbound Federation.
We are looking into Okta and we’d like to ask a few questions:
* Is there any support/training we can get for KeyCloak?
* Are there any customer success stories anyone can share?
* Does Keycloak provide and UI for inbound federation setup or Workflow
* What are the limits of key cloak with respect to scaling? What is the largest DB key cloak can work with, that someone has tried? (In terms of number of users)
* Do you provide any mechanism for adaptive authentication? Like requiring additional authentication steps based on authentication patterns (e.g. If a user logins from a different country than the one he has been logging in from usually, enforce a policy, like require MFA)
Thanks,
Sonia Marginean
@Bazaarvoice
9 years
programatically create user gives 400 bad request
by Dirk Franssen
Hi,
I have a standard keycloak 1.7.0-Final and a separate jax-rs service (both
in docker) to create a simple test-user programatically with hardcoded
params:
@Path("users")
@Stateless
public class UsersResource {
@POST
public Response createTestUser() {
Keycloak kc = Keycloak.getInstance(
"http://192.168.99.100:8180/auth",
"master",
"admin", "password",
"security-admin-console");
CredentialRepresentation credential = new
CredentialRepresentation();
credential.setType(CredentialRepresentation.PASSWORD);
credential.setValue("test123");
credential.setTemporary(false); /
UserRepresentation user = new UserRepresentation();
user.setUsername("testuser");
user.setFirstName("Test");
user.setLastName("User");
user.setCredentials(Arrays.asList(credential));
user.setEnabled(true);
user.setRealmRoles(Arrays.asList("admin"));
Response result = kc.realm("master").users().create(user);
return result;
}
}
But calling the JAX-RS endpoint returns in a delegated 400 Bad request. The
KC log states only:
00:40:23,436 WARN [org.keycloak.events] (default task-9) type=LOGIN_ERROR,
realmId=master, clientId=security-admin-console, userId=null,
ipAddress=172.17.0.1, error=not_allowed, grant_type=password,
auth_method=oauth_credentials, client_auth_method=client-secret
Any ideas?
Kind regards,
Dirk
9 years
