Re: [keycloak-user] Can not work from time to time for broke SAML 2.0 Identity provider
by Mai Zi
One observation from keycloak log is as below:
2016-01-16 18:12:33,067 WARN [org.keycloak.events] (default task-30) type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=UnileverHR, clientId=null, userId=null, ipAddress=180.107.103.49, error=identityProviderAuthenticationFailedMessage
2016-01-16 18:12:33,071 ERROR [org.keycloak.services.resources.IdentityBrokerService] (default task-30) identityProviderAuthenticationFailedMessage: org.keycloak.broker.provider.IdentityBrokerException: Invalid code, please login again through your client.
at org.keycloak.services.resources.IdentityBrokerService.parseClientSessionCode(IdentityBrokerService.java:551)
at org.keycloak.services.resources.IdentityBrokerService.authenticated(IdentityBrokerService.java:251)
at org.keycloak.broker.saml.SAMLEndpoint$Binding.handleLoginResponse(SAMLEndpoint.java:319)
at org.keycloak.broker.saml.SAMLEndpoint$Binding.handleSamlResponse(SAMLEndpoint.java:350)
at org.keycloak.broker.saml.SAMLEndpoint$Binding.execute(SAMLEndpoint.java:165)
at org.keycloak.broker.saml.SAMLEndpoint.postBinding(SAMLEndpoint.java:113)
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
In this case, we use the same account to lgoin from different clients at the same time. That is ,we may use two machines's browser to try to login into the same IDP account. I am not sure this is a legal case or not .
Thanks a lot
On Saturday, January 16, 2016 1:26 PM, Mai Zi <ornot2008(a)yahoo.com> wrote:
We user 1.7.0 final as SP to broke a SAML 2.0 IDP. We secure the realm for several clients . Here is the demo link : http://unihr.chinacloudapp.cn/campusNav/index.html?locale=en
The test account is
ID : S2\Testnew2Password : Daksh@123
We found keycloak works not stably . The response will be dead from time to time.
Pls take a try and help us . let me know what info you need.
Mai
8 years, 11 months
Can not work from time to time for broke SAML 2.0 Identity provider
by Mai Zi
We user 1.7.0 final as SP to broke a SAML 2.0 IDP. We secure the realm for several clients . Here is the demo link : http://unihr.chinacloudapp.cn/campusNav/index.html?locale=en
The test account is
ID : S2\Testnew2Password : Daksh@123
We found keycloak works not stably . The response will be dead from time to time.
Pls take a try and help us . let me know what info you need.
Mai
8 years, 11 months
Any limit on number of clients?
by Aikeaguinea
We have a number of devices that need to access APIs; for various
reasons we need to use client certificates for this purpose.
I have noticed that Keycloak will allow service accounts to authenticate
using client certificates and that these certificates can be generated
within Keycloak. This looks like it fits our needs well -- when we set
up a new device we would need to set up a new client and service account
for it in Keycloak. I've verified through testing that we can make this
work.
Ultimately we may have to manage a fairly large number of devices, say
in the hundreds. Is there any reason that Keycloak would limit us in the
number of clients we could create and manage in this way?
--
http://www.fastmail.com - Same, same, but different...
8 years, 11 months
A simple user login/registration in Keycloak
by Martin Min
Hello,
I have followed the keycloak "customer-portal" demo to learn KeyCloak, and
want to use it in an application, but have no idea of how to start with
KeyCloak. This is what I need:
On my home page, there is a typical user name login and registration box,
as you can see in many sites. How to configure KeyCloak and register in my
application so that after user types username and password, then Keyclaok
will do the job for me.
In the customer-demo, the user first click a link "customer-linking", which
redirects to the KeyCloak server for authentication, and this is configured
in Web.xml, in particular this section:
<security-constraint>
<web-resource-collection>
<web-resource-name>Customers</web-resource-name>
<url-pattern>/customers/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
In my case, users don't have to click a link to re-direct to Keycloak
server to accept user input. My home page directly provides users with the
user and password fields in the html form. How can i extend or modify the
customer-portal demo to set up a very basic user login functionality in
KeyClaok for my application?
I understand this is probably something very basic, but I appreciate any
feed back and information to achieve this.
Thank you.
8 years, 11 months
How to correctly use REST API? delete user through REST API for example
by JasonPeng
Hi there,
Can someone give me some hint about how to correctly setup a client that can
accept REST request from a httpclient in keycloak?
For example, I use the admin-access example from keycloak source project and
modify it to do a DELETE action through REST API, however I keep getting the
request Forbidden 403 from keycloak server. I don¹t change any setting of
the admin-client imported from the json file and my code snippet of deleting
user as below:
public static void deleteUser(HttpServletRequest request,
AccessTokenResponse res) throws Failure {
HttpClient client = new DefaultHttpClient();
String userId = "e20277f8-2ebe-4e5e-aa00-0cee9c578249";
try {
HttpDelete delete = new HttpDelete(getBaseUrl(request) +
"/admin/realms/demo/users/" + userId);
delete.addHeader("Authorization", "Bearer " + res.getToken());
HttpResponse response = client.execute(delete);
System.out.println(response.getStatusLine().getReasonPhrase());
if (response.getStatusLine().getStatusCode() != 200) {
throw new Failure(response.getStatusLine().getStatusCode());
}
HttpEntity entity = response.getEntity();
InputStream is = entity.getContent();
if (is != null)
is.close();
} catch (IOException e) {
throw new RuntimeException(e);
} finally {
client.getConnectionManager().shutdown();
}
}
8 years, 11 months
KEYCLOAK w/ NGINX Reverse Proxy
by Christopher Wallace
Community, I have spent a decent amount of time attempting to get KEYCLOAK
behind an NGINX Reverse Proxy to protect a TOMCAT Application. It does work
without the proxy, but I need the proxy to handle certificates. I think I
am pretty close to having it working, but somethings seems to be missing...
I have done the following. I appreciate any insight you may have as I think
I have exhausted other resources.
*1. Configure a server in NGINX*
server {
listen 443;
ssl on;
ssl_certificate /etc/ssl/certs/dcf30de94f28f16f.crt;
ssl_certificate_key /etc/ssl/certs/*.domain.key;
server_name sso2. domain.com;
access_log /var/log/nginx/nginx.sso.access.log;
error_log /var/log/nginx/nginx.sso.error.log;
location / {
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;
proxy_set_header X-Forwarded-Port 443;
proxy_pass http://internalip:8080;
}
}
*2. Enable SSL on a Reverse Proxy*
First add proxy-address-forwarding and redirect-socket to the http-listener
element:
<subsystem xmlns="urn:jboss:domain:undertow:1.1">
...
<http-listener name="default" socket-binding="http"
proxy-address-forwarding="true" redirect-socket="proxy-https"/>
...
</subsystem>
Then add a new socket-binding element to the socket-binding-group element:
<socket-binding-group name="standard-sockets"
default-interface="public"
port-offset="${jboss.socket.binding.port-offset:0}">
...
<socket-binding name="proxy-https" port="443"/>
...
</socket-binding-group>
*RECIVE THE FOLLOWING ERROR in TOMCAT:*
1807906 [http-nio-8080-exec-9] ERROR o.k.a.OAuthRequestAuthenticator -
failed to turn code into token
org.apache.http.conn.HttpHostConnectException: Connection to
https://sso2.domain.com refused
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:190)
~[httpclient-4.2.1.jar:4.2.1]
at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:151)
~[httpclient-4.2.1.jar:4.2.1]
at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:125)
~[httpclient-4.2.1.jar:4.2.1]
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
~[httpclient-4.2.1.jar:4.2.1]
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
~[httpclient-4.2.1.jar:4.2.1]
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
~[httpclient-4.2.1.jar:4.2.1]
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
~[httpclient-4.2.1.jar:4.2.1]
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
~[httpclient-4.2.1.jar:4.2.1]
at
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:90)
~[keycloak-adapter-core-1.7.0.Final.jar:1.7.0.Final]
at
org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:297)
[keycloak-adapter-core-1.7.0.Final.jar:1.7.0.Final]
at
org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:243)
[keycloak-adapter-core-1.7.0.Final.jar:1.7.0.Final]
at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:95)
[keycloak-adapter-core-1.7.0.Final.jar:1.7.0.Final]
at
org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.authenticateInternal(AbstractKeycloakAuthenticatorValve.java:189)
[keycloak-tomcat-core-adapter-1.7.0.Final.jar:1.7.0.Final]
at
org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve.authenticate(KeycloakAuthenticatorValve.java:28)
[keycloak-tomcat8-adapter-1.7.0.Final.jar:1.7.0.Final]
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470)
[lib/:na]
at
org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.invoke(AbstractKeycloakAuthenticatorValve.java:170)
[keycloak-tomcat-core-adapter-1.7.0.Final.jar:1.7.0.Final]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
[lib/:na]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
[lib/:na]
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
[lib/:na]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
[lib/:na]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516)
[lib/:na]
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086)
[tomcat-coyote.jar:8.0.18]
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659)
[tomcat-coyote.jar:8.0.18]
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
[tomcat-coyote.jar:8.0.18]
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558)
[tomcat-coyote.jar:8.0.18]
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515)
[tomcat-coyote.jar:8.0.18]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_25]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_25]
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
[tomcat-util.jar:8.0.18]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25]
Caused by: java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_25]
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
~[na:1.8.0_25]
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
~[na:1.8.0_25]
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
~[na:1.8.0_25]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[na:1.8.0_25]
at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_25]
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:649)
~[na:1.8.0_25]
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:549)
~[httpclient-4.2.1.jar:4.2.1]
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
~[httpclient-4.2.1.jar:4.2.1]
... 29 common frames omitted
8 years, 11 months
Re: [keycloak-user] keycloak-user Digest, Vol 25, Issue 61
by Aritz Maeztu
Marko, I think it is properly configured. Both the edge and the
organization service are part of the master realm. The only difference
is that access to edge is public and access to organization is
confidential. From the web browser, I have no problem in logging in to
the edge service and then going to the //organization/organizations/
path. The access to that path is not restricted in any other way.
14/01/2016 18:28(e)an, keycloak-user-request(a)lists.jboss.org igorleak
idatzi zuen:
> Send keycloak-user mailing list submissions to
> keycloak-user(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> or, via email, send a message with subject or body 'help' to
> keycloak-user-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> keycloak-user-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-user digest..."
>
>
> Today's Topics:
>
> 1. Re: Login to keycloak from Android app (Marko Strukelj)
> 2. Re: KEYCLOAK w/ NGINX Reverse Proxy (Christopher Wallace)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 14 Jan 2016 17:27:51 +0100
> From: Marko Strukelj <mstrukel(a)redhat.com>
> Subject: Re: [keycloak-user] Login to keycloak from Android app
> To: Iv?n Perdomo <ivan(a)akvo.org>
> Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
> Message-ID:
> <CA+1OW+idF1QD8ro+QOqvDMjrhZCA_Z1fMZdDvpCWjpzBCw87Sg(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Is the adapter for your 'organization' REST endpoint properly
> configured to use 'master' realm and 'edge' client?
>
> The keycloak.json config file in your organisation.war (or keycloak
> subsystem configuration) has to match that of 'edge' client
> configuration in your 'master' realm on Keycloak server.
>
> On Thu, Jan 14, 2016 at 4:38 PM, Iv?n Perdomo <ivan(a)akvo.org> wrote:
>> Hi,
>>
>> I tried this code some months ago and managed to login from Android.
>>
>> https://github.com/learning-layers/android-openid-connect
>>
>> Cheers,
>>
>> On 01/14/2016 04:29 PM, Aritz Maeztu wrote:
>>> Many thanks to all of you for the help. I'm so close to achieve it, so I
>>> need some last tip (and think you can do even about not to have mobile
>>> knowledge). That's the steps I've followed to authenticate a user in a
>>> public client in the Android app:
>>>
>>> 1- Launch a browser app pointing to keycloak's authorization site for
>>> the client:
>>>
>>> Intent i = new Intent(Intent.ACTION_VIEW,
>>> Uri.parse("http://192.168.0.230:8080/auth/realms/master/protocol/" +
>>>
>>> "openid-connect/auth?response_type=code&client_id=web_service&redirect_uri=android://app"));
>>> startActivity(i);
>>>
>>> 2- Retrieve the authorization code when coming back to my app and ask
>>> for an access token:
>>>
>>> RestTemplate template = new RestTemplate();
>>> template.getMessageConverters().add(new
>>> FormHttpMessageConverter());
>>> template.getMessageConverters().add(new
>>> MappingJackson2HttpMessageConverter());
>>> MultiValueMap<String, String> form = new
>>> LinkedMultiValueMap<>();
>>> form.add("grant_type", "authorization_code");
>>> form.add("client_id", "edge");
>>> form.add("code", accessCode);
>>> form.add("redirect_uri", "tcheck://app");
>>> ResponseEntity rssResponse = template.postForEntity(
>>>
>>> "http://192.168.0.230:8080/auth/realms/master/protocol/openid-connect/token",
>>> form,
>>> AccessToken.class);
>>>
>>> I'm passing the parameters in the request body as x-www-form-urlencoded
>>> and it works. I do get an access token, with this format:
>>>
>>> {
>>> "access_token" :
>>> "eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5OTEzYmRjOS1jZmI0LTRlZjAtYTcxYy0yYWUwYmQ3MTkwZDkiLCJleHAiOjE0NTI3NzUwNDQsIm5iZiI6MCwiaWF0IjoxNDUyNzc0OTg0LCJpc3MiOiJodHRwOi8vMTkyLjE2OC4wLjIzMDo4MDgwL2F1dGgvcmVhbG1zL21hc3RlciIsImF1ZCI6ImVkZ2UiLCJzdWIiOiJhNzE0NzAxNS0zNWM2LTRhZWEtYjNjOC1hNTY1ZTQ5YjcyZDkiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJlZGdlIiwic2Vzc2lvbl9zdGF0ZSI6IjdkZDVhZDdiLWQwYWItNGZiYS1iOWNiLWYzNjYxYTk5NGU3OSIsImNsaWVudF9zZXNzaW9uIjoiZDg2MzY1NjctMzg2MS00NjU5LTg0ZjItMDZjYmM5YTI3YTU1IiwiYWxsb3dlZC1vcmlnaW5zIjpbXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIlNVUEVSX0FETUlOIiwiY3JlYXRlLXJlYWxtIiwiVklFV19PUkdBTklaQVRJT04iLCJST0xFX1RDSEVDS19TVVBFUl9BRE1JTiIsIlJPTEVfVENIRUNLX0FETUlOIiwiYWRtaW4iXX0sInJlc291cmNlX2FjY2VzcyI6eyJtYXN0ZXItcmVhbG0iOnsicm9sZXMiOlsibWFuYWdlLWV2ZW50cyIsInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hbmFnZS1yZWFsbSIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwidmlldy1ldmVudHMiLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1h!
> bmF!
>>> nZS1jbGl
>>> lbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Iiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6IiIsInByZWZlcnJlZF91c2VybmFtZSI6ImFkbWluIn0.GMoAPe9aUQBRign5J0TvOt4tg1SWwyfJkvJjuWDZ_Ayj3GBnFjhgbjb5qLreKsm87NHymPcpvCv7uHkKJRsx44TjC0514O0oBSiVIiKfcJdbE-y7nPplzYAJF6I2JlsQkw9Na67vNSvhsBNg6AfBop4xpAF9HtTU7Ca7gFwOS01bgDRO09WlJYivzOd5t-vQGNwRVlTqaCstIMiBLaUfdkc82DNQwnoP5VO9R7xZn-7O5BE288_CX0C2V96_vooIoTbB3Qoa-gV6f3s6ZSyJnRGBgoe_2QY3mjCBarFQ_mKH_sbF2qMpm-a5igoNoD_3Xlc7iluP206ZJdQn4NZdQg",
>>> "expires_in" : 60,
>>> "refresh_expires_in" : 1800,
>>> "refresh_token" :
>>> "eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJkOTBmNzY5Ni00NDIwLTQ3NDUtYmQ3NS01Y2Q4MDNlMWY0YjQiLCJleHAiOjE0NTI3NzY3ODQsIm5iZiI6MCwiaWF0IjoxNDUyNzc0OTg0LCJpc3MiOiJodHRwOi8vMTkyLjE2OC4wLjIzMDo4MDgwL2F1dGgvcmVhbG1zL21hc3RlciIsImF1ZCI6bnVsbCwic3ViIjoiYTcxNDcwMTUtMzVjNi00YWVhLWIzYzgtYTU2NWU0OWI3MmQ5IiwidHlwIjoiUmVmcmVzaCIsImF6cCI6ImVkZ2UiLCJzZXNzaW9uX3N0YXRlIjoiN2RkNWFkN2ItZDBhYi00ZmJhLWI5Y2ItZjM2NjFhOTk0ZTc5IiwiY2xpZW50X3Nlc3Npb24iOiJkODYzNjU2Ny0zODYxLTQ2NTktODRmMi0wNmNiYzlhMjdhNTUiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsiU1VQRVJfQURNSU4iLCJjcmVhdGUtcmVhbG0iLCJWSUVXX09SR0FOSVpBVElPTiIsIlJPTEVfVENIRUNLX1NVUEVSX0FETUlOIiwiUk9MRV9UQ0hFQ0tfQURNSU4iLCJhZG1pbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7Im1hc3Rlci1yZWFsbSI6eyJyb2xlcyI6WyJtYW5hZ2UtZXZlbnRzIiwidmlldy1yZWFsbSIsInZpZXctaWRlbnRpdHktcHJvdmlkZXJzIiwibWFuYWdlLXJlYWxtIiwibWFuYWdlLWlkZW50aXR5LXByb3ZpZGVycyIsImltcGVyc29uYXRpb24iLCJ2aWV3LWV2ZW50cyIsImNyZWF0ZS1jbGllbnQiLCJtYW5hZ2UtdXNlcnMiLCJ2aWV3LXVzZXJzIiwidmlldy1jbGllbnRzIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY291!
> bnQ!
>>> iOnsicm9
>>> sZXMiOlsibWFuYWdlLWFjY291bnQiLCJ2aWV3LXByb2ZpbGUiXX19fQ.OZkivKxU1HJecrqKb1KDSabakruHJLUaUpNOy_DY7UW1R-4Qv6kLnPy_3soeRPP0FwYNrjzNMw94S-naE8JNCD91LqTTEyJ6o6q_1LDiDbVbfsKeyRkJDZDAbHUYtY-r35z_21SqdHxzzMcero6DoCpFaGOZZFQ86FZD7NiRE3oVzCIz1VJAFBIsSjH0W5_UQa2CEEIOxDanPnhbtdB8XZ6oQeKPB15AvobCgukvWcDufmCeJpUMcIjaTcnBdXRz6MIOp6VjQ5SyqJzn7jja8ILs3zEd8eeocAIix8Gv1CRs6PWBtWZJDss_fh4A8R2guKRBcFwQIeoncFgQeFeaoA",
>>> "token_type" : "bearer",
>>> "id_token" :
>>> "eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0OTUyOGQxNS1kZmEyLTQ1YTUtYjJiYy1hNzZhY2E2M2IwYjEiLCJleHAiOjE0NTI3NzUwNDQsIm5iZiI6MCwiaWF0IjoxNDUyNzc0OTg0LCJpc3MiOiJodHRwOi8vMTkyLjE2OC4wLjIzMDo4MDgwL2F1dGgvcmVhbG1zL21hc3RlciIsImF1ZCI6ImVkZ2UiLCJzdWIiOiJhNzE0NzAxNS0zNWM2LTRhZWEtYjNjOC1hNTY1ZTQ5YjcyZDkiLCJ0eXAiOiJJRCIsImF6cCI6ImVkZ2UiLCJzZXNzaW9uX3N0YXRlIjoiN2RkNWFkN2ItZDBhYi00ZmJhLWI5Y2ItZjM2NjFhOTk0ZTc5IiwibmFtZSI6IiIsInByZWZlcnJlZF91c2VybmFtZSI6ImFkbWluIn0.yOs1HGLQyV33ihDIzL4CiKlKj58zlZzNpJizOlWXg59DkdnL1W5RIT4-Jw5VToy267gWv1o0XIwI2oCVHjbaXKgWZzt7NlVdGnNyGL19VQUPlISlMyyoOhaBGufC4JycQ6BrQh0fnMYUVQOvGE6HGnVwUbrLHiVL579AVhUSmVZ052fzN4VySpm03L7eQBt6BTKMo_7fmL39WvdwY2gEhoi6rz2P8cXp8vbidwqb4nNF7C1wfM7GYgbO-1yaMq_c4JiOoga9YswD68XvKpjjwVZs2WvHpvwZrQjfiqa6EtxkTeRYncMW-RutB8P09wJ3WRaBooDreVBMFB2Tw6nWnQ",
>>> "not-before-policy" : 1452694301,
>>> "session-state" : "7dd5ad7b-d0ab-4fba-b9cb-f3661a994e79"
>>> }
>>>
>>> I now finally want to access some resource. As docs state, the only
>>> thing I want to do is to pass that access token in the Authorization
>>> header, starting with the Bearer keyword:
>>>
>>> HttpHeaders headers = new HttpHeaders();
>>> headers.set("Authorization", "Bearer " + token.getToken());
>>> HttpEntity<String> entity = new HttpEntity<>("parameters",
>>> headers);
>>> ResponseEntity rssResponse = template.exchange(
>>> "http://192.168.0.230:8765/organization/organizations",
>>> HttpMethod.GET,
>>> entity,
>>> OrganizationExchangeSet.class);
>>>
>>> But I get 401 Unauthorized from keycloak. If I do the GET request using
>>> Postman, I get the Unauthorized code too:
>>>
>>> Request:
>>>
>>> /Url:/
>>>
>>> http://192.168.0.230:8765/organization/organizations
>>>
>>> /Headers:/
>>>
>>> Authorization: Bearer
>>> eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5OTEzYmRjOS1jZmI0LTRlZjAtYTcxYy0yYWUwYmQ3MTkwZDkiLCJleHAiOjE0NTI3NzUwNDQsIm5iZiI6MCwiaWF0IjoxNDUyNzc0OTg0LCJpc3MiOiJodHRwOi8vMTkyLjE2OC4wLjIzMDo4MDgwL2F1dGgvcmVhbG1zL21hc3RlciIsImF1ZCI6ImVkZ2UiLCJzdWIiOiJhNzE0NzAxNS0zNWM2LTRhZWEtYjNjOC1hNTY1ZTQ5YjcyZDkiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJlZGdlIiwic2Vzc2lvbl9zdGF0ZSI6IjdkZDVhZDdiLWQwYWItNGZiYS1iOWNiLWYzNjYxYTk5NGU3OSIsImNsaWVudF9zZXNzaW9uIjoiZDg2MzY1NjctMzg2MS00NjU5LTg0ZjItMDZjYmM5YTI3YTU1IiwiYWxsb3dlZC1vcmlnaW5zIjpbXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIlNVUEVSX0FETUlOIiwiY3JlYXRlLXJlYWxtIiwiVklFV19PUkdBTklaQVRJT04iLCJST0xFX1RDSEVDS19TVVBFUl9BRE1JTiIsIlJPTEVfVENIRUNLX0FETUlOIiwiYWRtaW4iXX0sInJlc291cmNlX2FjY2VzcyI6eyJtYXN0ZXItcmVhbG0iOnsicm9sZXMiOlsibWFuYWdlLWV2ZW50cyIsInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hbmFnZS1yZWFsbSIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwidmlldy1ldmVudHMiLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hb!
> mFn!
>>> ZS1jbGll
>>> bnRzIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Iiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6IiIsInByZWZlcnJlZF91c2VybmFtZSI6ImFkbWluIn0.GMoAPe9aUQBRign5J0TvOt4tg1SWwyfJkvJjuWDZ_Ayj3GBnFjhgbjb5qLreKsm87NHymPcpvCv7uHkKJRsx44TjC0514O0oBSiVIiKfcJdbE-y7nPplzYAJF6I2JlsQkw9Na67vNSvhsBNg6AfBop4xpAF9HtTU7Ca7gFwOS01bgDRO09WlJYivzOd5t-vQGNwRVlTqaCstIMiBLaUfdkc82DNQwnoP5VO9R7xZn-7O5BE288_CX0C2V96_vooIoTbB3Qoa-gV6f3s6ZSyJnRGBgoe_2QY3mjCBarFQ_mKH_sbF2qMpm-a5igoNoD_3Xlc7iluP206ZJdQn4NZdQg
>>>
>>> /Response:/
>>>
>>> {
>>> "timestamp": 1452784544622,
>>> "status": 401,
>>> "error": "Unauthorized",
>>> "message": "Unable to authenticate bearer token",
>>> "path": "/organization/organizations"
>>> }
>>>
>>> How to solve this?
>>>
>>>
>>> --
>>> Aritz Maeztu Ota?o
>>> Departamento Desarrollo de Software
>>> <https://www.linkedin.com/profile/preview?vpa=pub&locale=es_ES>
>>> <http://www.tesicnor.com>
>>>
>>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra)
>>> Telf.: 948 21 40 40
>>> Fax.: 948 21 40 41
>>>
>>> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El
>>> medioambiente es cosa de todos.
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>> --
>> Iv?n
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 14 Jan 2016 17:28:10 +0000
> From: Christopher Wallace <cjwallac(a)gmail.com>
> Subject: Re: [keycloak-user] KEYCLOAK w/ NGINX Reverse Proxy
> To: Marko Strukelj <mstrukel(a)redhat.com>
> Cc: "keycloak-user(a)lists.jboss.org" <keycloak-user(a)lists.jboss.org>
> Message-ID:
> <CAKpG1FQbgx_TRqKQi21FjKx1S8t9_p2M-LXjDcR3Md9WHyxvfg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Again Marko Thanks for the information!
>
> We did already configure our standalone server like this. What I did find
> is that we updated the .JS adapter script and enable CORS
> http://serverfault.com/questions/162429/how-do-i-add-access-control-allow...
> Now
> we are getting to the TOKEN step in the life cycle
>
>
> 1. Request URL:
>
> https://sso2.company.com/auth/realms/master/protocol/openid-connect/token
> 2. Request Method:
> POST
> 3. Status Code:
> 400 Bad Request
> 4. Remote Address:
> 99.99.99.99:443
> 1. Response Headersview source
> 1. Connection:
> keep-alive
> 2. Content-Type:
> application/json
> 3. Date:
> Thu, 14 Jan 2016 17:10:45 GMT
> 4. Server:
> nginx/1.4.6 (Ubuntu)
> 5. Transfer-Encoding:
> chunked
> 6. X-Powered-By:
> Undertow/1
> 2. Request Headersview source
> 1. Accept:
> */*
> 2. Accept-Encoding:
> gzip, deflate
> 3. Accept-Language:
> en-US,en;q=0.8
> 4. Authorization:
> Basic bXByLXBsYXRmb3JtOmU1MGYxO
> 5. Connection:
> keep-alive
> 6. Content-Length:
> 202
> 7. Content-type:
> application/x-www-form-urlencoded
> 8. Cookie:
>
> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiIzOWIxMzg3OS1mYjY5LTQ2MTAtYTdlZS1mZjA2ZjgyOTI4MzUiLCJleHAiOjE0NTI4Mjc0NDcsIm5iZiI6MCwiaWF0IjoxNDUyNzkxNDQ3LCJpc3MiOiJodHRwczovL3NzbzIubWVkaWNhbHBheXJldmlldy5jb20vYXV0aC9yZWFsbXMvbWFzdGVyIiwiYXVkIjpudWxsLCJzdWIiOiJhNWM2MzJiYy0xNmNlLTQ3NzgtOGNmMy05MWQ4MmMzNTE3NmYiLCJzZXNzaW9uX3N0YXRlIjoiYjkwMTViMGItYTUyNC00ZDVkLWJiYjMtMDI2OTk3NjY0NjM1IiwicmVzb3VyY2VfYWNjZXNzIjp7fX0.nCUDrU2Q9DQM5c2xcxLoW1pqVJNYcc-ZCUWe6HTlBVh1rwwk0V1q15Mbq0HzWcEkDWqatUTTQ0PEysH18hsOzuJdqRaaplBURwzW4S
> 9. DNT:
> 1
> 10. Host:
> sso2.company.com
> 11. Origin:
> http://portal.app.company.local.medicalpayreview.com
> 12. Referer:
> http://portal.app.company.local.medicalpayreview.com/App/
> 13. User-Agent:
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36
> (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
> 3. Form Dataview sourceview URL encoded
> 1. code:
>
> Mk9BGw2vGHNBtO-caT1Z1MEpwixV4Ke5yi5YFEubDes.d82b1938-d6a6-4c3c-99eb-0a0d1c2636be
> 2. grant_type:
> authorization_code
> 3. redirect_uri:
> http://portal.app.local.medicalpayreview.com/App/
>
>
> We find the following WARNING in the KEYCLOAK logs
>
> 17:10:48,891 WARN [org.keycloak.events] (default task-13)
> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=platform, userId=null,
> ipAddress=72.77.99.99, error=invalid_client_credentials,
> grant_type=authorization_code
>
> And and error the browser console:
>
> XMLHttpRequest cannot load
> https://sso2.medicalpayreview.com/auth/realms/master/protocol/openid-conn....
> No 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'http://portal.app.company.local.medicalpayreview.com' is
> therefore not allowed access. The response had HTTP status code 400.
>
> We appreciate everyones input on getting over this challenge.
>
>
>
> On Thu, Jan 14, 2016 at 10:06 AM Marko Strukelj <mstrukel(a)redhat.com> wrote:
>
>> Maybe take a look at advice in this thread:
>> http://lists.jboss.org/pipermail/keycloak-user/2016-January/004413.html
>>
>> On Thu, Jan 14, 2016 at 3:44 PM, Christopher Wallace <cjwallac(a)gmail.com>
>> wrote:
>>> Marko, Thanks for your feedback!
>>>
>>> We have successfully pass that problem and are able to login to KEYCLOAK
>>> behind NGINX using HTTPS Proxy. Our challenge now is when our
>> applications
>>> attempt to access we get the following error:
>>>
>>> Request URL:
>>> https://sso2.company.com/auth/realms/master/tokens/access/codes
>>> Request Method:
>>> POST
>>> Status Code:
>>> 400 Bad Request
>>> Remote Address:
>>> 99.99.99.99:443
>>>
>>> Response Headersview source
>>>
>>> Connection:
>>> keep-alive
>>> Content-Type:
>>> application/json
>>> Date:
>>> Thu, 14 Jan 2016 14:35:52 GMT
>>> Server:
>>> nginx/1.4.6 (Ubuntu)
>>> Transfer-Encoding:
>>> chunked
>>> X-Powered-By:
>>> Undertow/1
>>>
>>> Request Headersview source
>>>
>>> Accept:
>>> */*
>>> Accept-Encoding:
>>> gzip, deflate
>>> Accept-Language:
>>> en-US,en;q=0.8
>>> Authorization:
>>> Basic bXByLXBsYXRmb3JtOmU1MGYxODEyLTYzYTQtNGM0YS05NWQ
>>> Connection:
>>> keep-alive
>>> Content-Length:
>>> 172
>>> Content-type:
>>> application/x-www-form-urlencoded
>>> Cookie:
>>>
>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiIzNGY0ZDI1OS02NzJjLTQzYjUtOGFmOC1hNzkwMWRiMDUxMmYiLCJleHAiOjE0NTI4MTgxNTMsIm5iZiI6MCwiaWF0IjoxNDUyNzgyMTUzLCJpc3MiOiJodHRwczovL3NzbzIubWVkaWNhbHBheXJldmlldy5jb20vYXV0aC9yZWFsbXMvbWFzdGVyIiwiYXVkIjpudWxsLCJzdWIiOiJhNWM2MzJiYy0xNmNlLTQ3NzgtOGNmMy05MWQ4MmMzNTE3NmYiLCJzZXNzaW9uX3N0YXRlIjoiOWRiNjdhNGQtOWIwMS00NjgxLTlmYmMtZDQ3N2Y1NTgyMGYyIiwicmVzb3VyY2VfYWNjZXNzIjp7fX0.JyQIOJk5214-n4y0RkpEuLJWY4u6Z4Fu_086Z9nwM9BU8TarV-oH6cxZEBYakyL8pvmwf0CWHMmN3XNF-Zv4b1UPutcLP7IChM1EEr4F1tPxwmddYS1M90NdY7Bzn2R36mnASZqczMMAisd-OE2TU8oDgMyg0Rb0iZNIi_jJU_Rd-na4qhfuBojF_u8BSFjSJsd3agjF5ZZ9ok9mo2McCMDaV21vozVryIkR1vfAKPWf6WI8fEQBpDAFsh37M_k
>>> DNT:
>>> 1
>>> Host:
>>> sso2.company.com
>>> Origin:
>>> http://app.local.company.com
>>> Referer:
>>> http://app.local.company.com/App/
>>> User-Agent:
>>> Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36
>> (KHTML,
>>> like Gecko) Chrome/47.0.2526.106 Safari/537.36
>>>
>>> Form Dataview sourceview URL encoded
>>>
>>> code:
>>>
>> Vyzj7f-Aq2anYTJy7AoK4e6h0s2Ypp0vQ6okx7lWlRo.d2acab15-f708-4838-bd4b-2562fd46f8e2
>>> redirect_uri:
>>> http://app.local.company.com/App/
>>>
>>> Please do note that this same application is able KEYCLOAK using
>> basically
>>> the same configuration without NGINX in the MIX. Have any thoughts was to
>>> what we should look to configure differently with NGIX in the mix?
>>>
>>> On Mon, Jan 4, 2016 at 7:16 AM Marko Strukelj <mstrukel(a)redhat.com>
>> wrote:
>>>> The error 'org.apache.http.conn.HttpHostConnectException: Connection to
>>>> https://sso2.domain.com refused' means that either there is a server
>> side
>>>> problem - your Nginx isn't started and listening on port 443, a firewall
>>>> preventing incoming connections - or there is a client side problem - a
>> DNS
>>>> issue improperly resolving sso2.domain.com into IP on the host where
>> Tomcat
>>>> is running.
>>>>
>>>> At this point no SSL handshaking was attempted yet.
>>>>
>>>> If you try 'curl https://sso2.domain.com' or 'telnet sso2.domain.com
>> 443'
>>>> from the server running your Tomcat you'll see the same issue. Once that
>>>> starts to work, only then will any SSL / proxying related configuration
>>>> issues start to manifest themselves.
>>>>
>>>> On Wed, Dec 30, 2015 at 11:34 PM, Christopher Wallace <
>> cjwallac(a)gmail.com>
>>>> wrote:
>>>>> Community, I have spent a decent amount of time attempting to get
>>>>> KEYCLOAK behind an NGINX Reverse Proxy to protect a TOMCAT
>> Application. It
>>>>> does work without the proxy, but I need the proxy to handle
>> certificates. I
>>>>> think I am pretty close to having it working, but somethings seems to
>> be
>>>>> missing... I have done the following. I appreciate any insight you may
>> have
>>>>> as I think I have exhausted other resources.
>>>>>
>>>>> 1. Configure a server in NGINX
>>>>>
>>>>> server {
>>>>>
>>>>> listen 443;
>>>>>
>>>>>
>>>>> ssl on;
>>>>>
>>>>> ssl_certificate /etc/ssl/certs/dcf30de94f28f16f.crt;
>>>>>
>>>>> ssl_certificate_key /etc/ssl/certs/*.domain.key;
>>>>>
>>>>>
>>>>> server_name sso2. domain.com;
>>>>>
>>>>> access_log /var/log/nginx/nginx.sso.access.log;
>>>>>
>>>>> error_log /var/log/nginx/nginx.sso.error.log;
>>>>>
>>>>> location / {
>>>>>
>>>>> 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;
>>>>>
>>>>> proxy_set_header X-Forwarded-Port 443;
>>>>>
>>>>> proxy_pass http://internalip:8080;
>>>>>
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> 2. Enable SSL on a Reverse Proxy
>>>>>
>>>>> First add proxy-address-forwarding and redirect-socket to the
>>>>> http-listener element:
>>>>>
>>>>> <subsystem xmlns="urn:jboss:domain:undertow:1.1">
>>>>> ...
>>>>> <http-listener name="default" socket-binding="http"
>>>>> proxy-address-forwarding="true" redirect-socket="proxy-https"/>
>>>>> ...
>>>>> </subsystem>
>>>>>
>>>>> Then add a new socket-binding element to the socket-binding-group
>>>>> element:
>>>>>
>>>>> <socket-binding-group name="standard-sockets"
>> default-interface="public"
>>>>> port-offset="${jboss.socket.binding.port-offset:0}">
>>>>> ...
>>>>> <socket-binding name="proxy-https" port="443"/>
>>>>> ...
>>>>> </socket-binding-group>
>>>>>
>>>>>
>>>>> RECIVE THE FOLLOWING ERROR in TOMCAT:
>>>>>
>>>>> 1807906 [http-nio-8080-exec-9] ERROR o.k.a.OAuthRequestAuthenticator -
>>>>> failed to turn code into token
>>>>>
>>>>> org.apache.http.conn.HttpHostConnectException: Connection to
>>>>> https://sso2.domain.com refused
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:190)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:151)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:125)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:90)
>>>>> ~[keycloak-adapter-core-1.7.0.Final.jar:1.7.0.Final]
>>>>>
>>>>> at
>>>>>
>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:297)
>>>>> [keycloak-adapter-core-1.7.0.Final.jar:1.7.0.Final]
>>>>>
>>>>> at
>>>>>
>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:243)
>>>>> [keycloak-adapter-core-1.7.0.Final.jar:1.7.0.Final]
>>>>>
>>>>> at
>>>>>
>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:95)
>>>>> [keycloak-adapter-core-1.7.0.Final.jar:1.7.0.Final]
>>>>>
>>>>> at
>>>>>
>> org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.authenticateInternal(AbstractKeycloakAuthenticatorValve.java:189)
>>>>> [keycloak-tomcat-core-adapter-1.7.0.Final.jar:1.7.0.Final]
>>>>>
>>>>> at
>>>>>
>> org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve.authenticate(KeycloakAuthenticatorValve.java:28)
>>>>> [keycloak-tomcat8-adapter-1.7.0.Final.jar:1.7.0.Final]
>>>>>
>>>>> at
>>>>>
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470)
>>>>> [lib/:na]
>>>>>
>>>>> at
>>>>>
>> org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.invoke(AbstractKeycloakAuthenticatorValve.java:170)
>>>>> [keycloak-tomcat-core-adapter-1.7.0.Final.jar:1.7.0.Final]
>>>>>
>>>>> at
>>>>>
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
>>>>> [lib/:na]
>>>>>
>>>>> at
>>>>>
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>>>>> [lib/:na]
>>>>>
>>>>> at
>>>>>
>> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
>>>>> [lib/:na]
>>>>>
>>>>> at
>>>>>
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
>>>>> [lib/:na]
>>>>>
>>>>> at
>>>>>
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516)
>>>>> [lib/:na]
>>>>>
>>>>> at
>>>>>
>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086)
>>>>> [tomcat-coyote.jar:8.0.18]
>>>>>
>>>>> at
>>>>>
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659)
>>>>> [tomcat-coyote.jar:8.0.18]
>>>>>
>>>>> at
>>>>>
>> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
>>>>> [tomcat-coyote.jar:8.0.18]
>>>>>
>>>>> at
>>>>> org.apache.tomcat.util.net
>> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558)
>>>>> [tomcat-coyote.jar:8.0.18]
>>>>>
>>>>> at
>>>>> org.apache.tomcat.util.net
>> .NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515)
>>>>> [tomcat-coyote.jar:8.0.18]
>>>>>
>>>>> at
>>>>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>>> [na:1.8.0_25]
>>>>>
>>>>> at
>>>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>>> [na:1.8.0_25]
>>>>>
>>>>> at
>>>>>
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>>>>> [tomcat-util.jar:8.0.18]
>>>>>
>>>>> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25]
>>>>>
>>>>> Caused by: java.net.ConnectException: Connection timed out
>>>>>
>>>>> at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_25]
>>>>>
>>>>> at
>>>>> java.net
>> .AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
>>>>> ~[na:1.8.0_25]
>>>>>
>>>>> at
>>>>> java.net
>> .AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
>>>>> ~[na:1.8.0_25]
>>>>>
>>>>> at
>>>>> java.net
>> .AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
>>>>> ~[na:1.8.0_25]
>>>>>
>>>>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>>>> ~[na:1.8.0_25]
>>>>>
>>>>> at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_25]
>>>>>
>>>>> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:649)
>>>>> ~[na:1.8.0_25]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:549)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> at
>>>>>
>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
>>>>> ~[httpclient-4.2.1.jar:4.2.1]
>>>>>
>>>>> ... 29 common frames omitted
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user(a)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/20160114/02aa8...
>
> ------------------------------
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> End of keycloak-user Digest, Vol 25, Issue 61
> *********************************************
--
Aritz Maeztu Otaño
Departamento Desarrollo de Software
<https://www.linkedin.com/profile/preview?vpa=pub&locale=es_ES>
<http://www.tesicnor.com>
Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra)
Telf.: 948 21 40 40
Fax.: 948 21 40 41
Antes de imprimir este e-mail piense bien si es necesario hacerlo: El
medioambiente es cosa de todos.
8 years, 11 months
Login to keycloak from Android app
by Aritz Maeztu
Hello everybody,
I'm struggling to implement a keycloak login from my Android app. What I
want to do is to simulate what a browser does (request a resource, be
redirected to keycloak login page and get an access token later on).
From what I've seen from the OAuth2 protocol, I need to firstly get the
authorization code and later on request the access token with that code.
I wouldn't like my Android app to be registered as a client itself, so
I've registered my web service as public.
Here I start the intent to launch the Android browser pointing to the
keycloak authorization address (/openid-connect/auth):
Intent i = new Intent(Intent.ACTION_VIEW,
Uri.parse("http://192.168.0.230:8080/auth/realms/master/protocol/" +
"openid-connect/auth?response_type=code&client_id=web_service&redirect_uri=android://app"));
startActivity(i);
When I enter the credentials successfully, I'm given a code in the
redirection url, coming back to my app:
Uri data = getIntent().getData();
if (data != null) {
String accessCode= data.getQueryParameter("code");
System.out.println("Authorization code:" + accessCode);
}
The code looks like
bC8OM0TwfbhYouM34M3RY2aZRYTywXZVAvKFABgvVRc.693363de-d6b5-4f88-b545-c6603023ee4c
Then I would like to get an access token with that code! I use a Rest
Template for that, making a POST request to the /openid-connect/token
endpoint:
ResponseEntity rssResponse = template.exchange(
"http://192.168.0.230:8080/auth/realms/master/protocol/" +
"openid-connect/token?grant_type=authoritation_code&client_id=web_service&code="+accessCode,
HttpMethod.POST,
null,
Object.class);
However, I'm given a 401 unauthorized exception. What am I doing wrong?
Thanks in advanced ;-)
--
Aritz Maeztu Otaño
Departamento Desarrollo de Software
<https://www.linkedin.com/profile/preview?vpa=pub&locale=es_ES>
<http://www.tesicnor.com>
Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra)
Telf.: 948 21 40 40
Fax.: 948 21 40 41
Antes de imprimir este e-mail piense bien si es necesario hacerlo: El
medioambiente es cosa de todos.
8 years, 11 months
Keycloak 1.8.0.CR1 Released
by Stian Thorgersen
Keycloak 1.8.0.CR1 has just been released. As usual we will follow with a
final release next week as long as no major issues are reported.
- *Default Admin User Removed* - we no longer have a built in admin
account, instead a new account has to be created initially from
http://localhost:8080/auth or with the bin/add-user[sh|bat] script
- *Client Templates* - with the introduction of client templates it's
now possible to share mappers and scope configuration between clients
- *Partial Import* - it's now possible to import users, clients,
identity brokers and user federators from a json file into an existing realm
- *Truststore SPI* - we've introduced a Truststore SPI which provides a
centralized place to manage the truststore for clients, email, user
federation and identity brokering
- *Password Hashing SPI* - if you want to import existing users into
Keycloak you can implement a password hashing provider so existing hashed
passwords can be used (thanks to tsudo <https://github.com/tsudot> for
the contribution)
- *Identity Brokering Login Flow* - this allows customizing the flow
used when a user logs in through an identity broker
- *SAML v2 Enhanced Client or Proxy Profile (ECP)
<http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile>* - this
SAML profile is useful for non-browser based clients (for example a desktop
application)
- *OAuth2 Token Introspection <https://tools.ietf.org/html/rfc7662>* -
the OAuth2 token introspection specification provides a standard way to
obtain the active state of a token
- *Conditional OTP* - requiring OTP used to be either enabled or
disabled for a realm, it's now possible to conditionally choose which users
require OTP based on for example a role or a request header (thanks to
thomasdarimont <https://github.com/thomasdarimont> for the contribution)
- *Realm Display Name* - a display name has been added to realms, which
makes it possible to set a human readable name to be shown on login
screens, emails, etc.
- *WildFly 10.0.0.CR5* - Keycloak is now built on top of WildFly
10.0.0.CR5. Deploying the server overlay to WildFly 9 is no longer supported
For the full list of issues resolved check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fix...>
and
to download the release go to the Keycloak homepage
<http://keycloak.org/downloads>.
8 years, 11 months
Property name not translated
by Helder dos S. Alves
Hi.
The "Account Already Exists" page is not translated correctly.
The message:
federatedIdentityConfirmLinkMessage=User with {0} {1} already exists. How
do you want to continue?
The {0} comes with the property name (email).
The property name should come translated. Example: "E-mail" in portuguese
and german, "Courriel" in french.
Regards.
Helder S. Alves
8 years, 11 months
