CORS REST request blocked by browser
by alex orl
Hi to all,in my use case i have a typical web application made up on a frontend layer written completely with Angular js and a REST server layer wirtten with jersey 2.0.Till now i made my test simply securing the REST layer using web.xml descriptor and registering it as webapplication client into keycloak realm. The security type was confidential.Simply invoking a service REST url i was redirected to the keycloak login page where i could insert my credential and so on....Now i want to go further... it's the turn of the angular js application. It invokes obviously the rest services and it has to be secured. The keycloak CORS example shows a use case similar to the mine one, so i choose to follow it. I realize that it adds a javascript adapter to the Angular level without registering the service webapplication inside the CORS realm.On keycloak guidelines i read that this is not the best way to follow as securing the application this way makes to loose the confidential data transport between client and server.By the way... i try 2 approaches to the problem:
1)following exactly the CORS example: i added the js adapter to the angular js application; i configured only the client inside my realm as public, and eventually imported the keycloak.js. Result: when i run the application i'm redirected to the keycloak login page; i filled out the form but after the login i'm blocked by the browser because it does'nt find the access-control-allow-origin header in the get token request. The keycloak.json in the WEB-INF folder of the rest service specifies enabled-cors:true
2)i left the REST layer secured expecting that at the first angular REST request i should be redirected to the keycloak login page. But even in this case browser blocks me because it misses access control allow origin header. Even in this case the keycloak.json in the WEB-INF folder of the rest service specifies enabled-cors:true
So where am i wrong?What is the right approach for securing my web application?Why browser continues blocking my request?
11 years
retrieving custom user attributes
by Arjan Lamers
Hi,
I am trying to find an easy way to access custom attributes as defined for
a client. For a Keycloak client, I’ve defined a new Mapper for a *user
attribute* to store some additional authorisation data. This then is
managed by some user domain that uses the keycloak-admin-client to write
that property.
The problem arises when I want to access that property in an JEE
application.The way I do it right now to use the KeycloakPrincipal found in
the javax.ejb.SessionContext. From there, I get the JWT token as a String,
deserialize the JSON and access the custom attribute from there.
This feels like a very roundabout way to get to the token but somehow I am
not able to find an easier way. Is it a missing feature or is it simply too
close to the weekend for me ;)?
See
http://www.first8.nl/blog/security-with-microservices-programmatic-securi...
for
a blog post with more details.
Thanks and kind regards,
Arjan Lamers
--
Met vriendelijke groet,
Arjan Lamers
---------------------------------------------------------------------------------------
“God in his wisdom made the fly / And then forgot to tell us why. ”
- Ogden Nash
First Eight BV
KvK dossiernr: 30.17.95.44
Gemeente Utrecht
Kerkenbos 10-59b
6546 BB Nijmegen
T: 024-3483570
F: 024-3483571
E: a.lamers(a)first8.nl
W: www.first8.nl
Op alle offertes, aanbiedingen of overeenkomsten van First Eight BV zijn,
tenzij expliciet anders overeengekomen, de Algemene Voorwaarden van
Conclusion B.V. van toepassing, welke zijn te vinden op www.conclusion.nl.
Tevens zijn deze gedeponeerd bij de Kamer van Koophandel Midden-Nederland
onder nummer 16059253. Op schriftelijk verzoek zullen de Algemene
Voorwaarden u kosteloos worden toegezonden.
De inhoud van dit e-mailbericht is uitsluitend bestemd voor de
geadresseerde(n). Gebruik van de inhoud daarvan door anderen of
verzending aan anderen is zonder toestemming van de afzender of
geadresseerde(n) onrechtmatig. Mocht dit e-mailbericht ten onrechte bij
u terechtgekomen zijn, dan verzoeken wij u onmiddellijk contact met ons op
te nemen. First Eight BV betracht de grootst mogelijke zorgvuldigheid bij
het voorkomen van virussen in de bijlage(n) bij dit bericht. Desondanks
dient u zelf de bijlage(n) te controleren op de aanwezigheid van virussen
en kan First Eight BV niet aansprakelijk worden gehouden indien bijlage(n)
schade, waaronder schade aan computer(systeem), veroorzaken.
11 years
deletion execution schedule EVENT_ENTITY
by Hipfinger Martin (BCC.ÖBB.TicketShop.MA)
Hi,
we've enabled event logging in Realm -> Events -> Config: Save Events ON, Expiration: 365 days
KC executes the following statement every 15 minutes: delete from EVENT_ENTITY where REALM_ID=:1 and EVENT_TIME<:2
As the table event_entity is quite big, we'd like to reduce the frequency of deletion - so I'd like to ask if there is any possibility to change the execution schedule of deletion?
Thx & br,
Martin
11 years
update token: CORS error after session timeout
by Tair Sabirgaliev
Hi,
I’m integrating a web application using angularjs 1.4.6 and keycloak 1.5.0.
The application and keycloak app-servers are on different ports.
The application works ok when the session is not expired.
After session expiration keycloak.updateToken() fails with
400 Bad Request. Chrome shows the following in the console:
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/protocol/openid-connect/token. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:9080' is therefore not allowed access. The response had HTTP status code 400.
The behavior is same with Safari and Firefox.
If I get it right, this 400 response from keycloak shouldn’t be
interpreted as CORS failure by browsers?
This is keycloak response when session is alive:
--> HTTP/1.1 200 OK
X-Powered-By: Undertow/1
Server: WildFly/9
Access-Control-Expose-Headers: Access-Control-Allow-Methods
Date: Tue, 29 Sep 2015 04:54:52 GMT
Connection: keep-alive
Access-Control-Allow-Origin: http://localhost:9080
Access-Control-Allow-Credentials: true
Transfer-Encoding: chunked
Content-Type: application/json
And this one with session expired:
--> HTTP/1.1 400 Bad Request
Connection: keep-alive
X-Powered-By: Undertow/1
Server: WildFly/9
Transfer-Encoding: chunked
Content-Type: application/json
Date: Tue, 29 Sep 2015 04:55:03 GMT
So my concerns are:
1. Why CORS headers depend on session validity? This caused much confusion for me,
because I thought there is a problem with CORS, until I understood this was session problem.
2. I think it would also be great to have some more context on error responses
(like returning some json with error description), because HTTP responses are too generic.
--
Tair Sabirgaliev
Bee Software, LLP
11 years
Use Case and Roadmap
by Giovanni Baruzzi
Dear KeyCloak team,
In the last days I worked intensively with KeyCloak, trying to check if it fits as a solution in a current project and I was suddenly aware of the big potential still hidden in the software.
The problem is, that these capabilities can be understood only after hours of experimenting and I was able to appreciate the vision behind it.
There is not too much trace of the vision in the documentation, which is not bad, but it does not tell you why some feature are there and how to better make use of them.
So, a kind request: can you publish some document telling why you decided to implement a feature?
These contributions don’t need to be extensive, it gives just us a glimpse of the gold buried in the project.
A road map or a list of features under evaluation could be very useful too.
Thank you,
Giovanni
11 years
Wrapping Keycloak under Nginx - redirect_uri problems
by Kevin Thorpe
Hi, I'm trying to wrap Keycloak behind Nginx for a client and I can't work
out how to
avoid the invalid parameter: redirect_uri problem.
Website is https://my-client.pibenchmark.com
In nginx:
location /auth {
proxy_pass https://auth-service;
}
upstream auth-service {
server my-keycloak:8443;
}
Then in Keycloak I have valid redirect URIs set to https://*.
pibenchmark.com/* ie my whole domain. Still getting invalid parameter:
redirect_uri though.
What am I doing wrong? Can I do this this way? I like to have one point of
contact with the internet for security reasons.
*Kevin Thorpe*
CTO, PI Limited
11 years
Role to claim mapping
by Gonzalo López
I'm trying to test the Identity broker to achieve cross domain sso, this is
what I have done:
1 - Installed jboss 6.4 eap + keycloak + keycloak eap6 adapter in host A
2 - Installed jboss 6.4 eap + keycloak in host B
3 - In host A, I added an oidc Identity Provider (importing host B openid
connect configuration).
4 - In host A, I created an application (appa.war) that will try to use the
broker to authenticate. I added security to the app (only user with role
"user" will be able to access some parts)
5 - In host B, I added 2 oidc clients (the broker from host A and appb,
appb (appb.war) is a simple application developed to log in using oidc)
6 - In host B, I created a role "testrole" inside appb and a user
"testuser", then I added that role to the user.
I couldn't find out how to map the role "testrole" to a claim that will be
sent to the broker once the user has authenticated. Is there a way to do
that?
After I accomplish that I plan to map that claim to the role appa.user.
11 years
Login page for external IDP using SAML
by robinfernandes .
Hi All,
I was trying to setup Keycloak to use SAML and configure an external IDP in
the admin console of Keycloak.
I had a couple of questions :
1. What is the keycloak API we need to hit to access the landing page for
the external IDP?
2. I was trying to call the /realm/{realm-name}/broker/{provider-id}/login
API
The problem that I was facing when I used the above API was that it expects
"code" as the Query parameter and I did not find any example on how to
generate that code.
Any help would be appreciated.
Thanks,
Robin
11 years
ports confusion
by Tim Dudgeon
I'm having problems getting keycloak running on AWS using the docker
files on docker hub.
I'm using this docker compose configuration:
postgres:
image: postgres
ports:
- "5432:5432"
environment:
- POSTGRES_DATABASE=keycloak
- POSTGRES_USER=keycloak
- POSTGRES_PASSWORD=keycloak
keycloak:
image: jboss/keycloak-postgres
ports:
- "8080:8080"
links:
- postgres:postgres
environment:
- POSTGRES_DATABASE=keycloak
- POSTGRES_USER=keycloak
- POSTGRES_PASSWORD=keycloak
This works fine when I'm running on a local machine, but when I run on
AWS I can get a response from the default http://<host>:8080/ address
but when I try to connect to the Admin console it give error saying
HTTPS is required.
Probably some required port is not open but I'm not sure what.
What is strange is that the dockerfile for the base keycloak image
(https://hub.docker.com/r/jboss/keycloak/~/dockerfile/) shows that only
port 8080 is exposed, not any ports for SSL.
Any suggestions for what's going on here?
Tim
11 years
OpenID Connect discovery with Play Framework
by Bruce Shaw
Hello,
I’m evaluating Keycloak as an identity provider for a few Play Framework projects using pac4j-play as the OpenID Connect client.
There isn’t an adapter for Play so I thought I could leverage the discovery endpoint with my client to authenticate. I wasn’t able to find any details on this in the documentation but after a little bit of digging I found the "well-known" uri that I configured with our client to authenticate successfully with our Keycloak instance.
So because I couldn’t find much on this I was curious if this approach for authentication is recommended or supported. Also, what is the difference in action between logging out with the “end_session_endpoint” provided by the discovery metadata versus the logout url in the documentation: “http://auth-server/auth/realms/{realm-name}/tokens/logout?redirect_uri=encodedRedirectUri” ?
thanks,
Bruce
***NOTICE*** This e-mail and/or the attached documents may contain technical data within the definition of the International Traffic in Arms Regulations and/or Export Administration Regulations, and are subject to the export control laws of the U.S. Government. Transfer of this data by any means to a foreign person, whether in the United States or abroad, without an export license or other approval from the U.S. Department of State or Commerce, as applicable, is prohibited. No portion of this e-mail and/or correspondence its attachment(s) may be reproduced without written consent of Mainstream Engineering Corporation. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.
This electronic message (including any attachments) contains information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although Mainstream Engineering Corporation has taken reasonable precautions to ensure no viruses are present in this email, Mainstream accepts no responsibility for any loss or damage arising from the use of this email or attachments.
11 years
