1:43 a.m.
Hi Bill,it's a mixed approach, maybe this is confusing you.
I don't understand what the flow is below. In your flow above
you said
your server is making a call to the backend service with the token and
is authenticated correctly, right?
My frontend is a WAR running on Tomcat and it is secured by keycloak.
What I don't understand is what you are doing below. Are you
saying you > have a Browser client (Javascript) making a call to your backend?
The WAR serves also an AngularJS dashboard, in this dashboard I
"inject" the token from the server but then I make client side calls.
The flow is:
1- The user call http://.../dashboard
2- The frontend server redirects to the keycloak login
3- Keycloak authenticates the user and redirects to frontend server
4- The frontend server serves the AngularJS dashboard injecting the token
5- The client side dashboard makes ajax calls to the backend to load data
At point 5 I see my backend is logging that the call is AUTHENTICATED
but on client side I see the response is failing.
--
Davide
11:28 a.m.
New subject: How to secure JAX-RS service based on reasteasy running on undertow
Hi Davide,
I would suggest to change your flow a bit. You have frontend JEE servlet
application, which is authenticated with Keycloak. So I think that you
don't need any Keycloak accessTokens to be shared with your AngularJS
dashboard at all. I would suggest that your AngularJS dashboard won't
communicate directly with your JAX-RS backend application, but instead
it will communicate just with your servlet JEE application, which will
then re-send request to JAX-RS application with the usage of
KeycloakSecurityContext as shown in the customer-portal example. So
assuming that your frontend application is on
"http://localhost:8080/frontend" and your JAX-RS is at
"http://localhost:8080/backend" you can do:
1- The user call http://.../frontend
2- Thefrontendserver redirects to the keycloak login
3- Keycloak authenticates the user and redirects to frontendserver
4- The frontend server serves the AngularJS dashboard but NOT injecting the token (So
angularJS and your browser don't have direct access to token at all)
5- User clicks to something in AngularJS app, which will send request to
http://localhost:8080/frontend/someEndpoint
6- Frontend will re-send this to http://localhost:8080/backend/someBackendEndpoint
similarly as shown in examples, which will ensure that frontend application will attach
Bearer token to the request
7- After backend request is done and received in "frontend" app, it will resend
it back to AngularJS with all the data.
So your frontend app will be defacto proxy between AngularJS and "backend"
JAX-RS application. With this design, you won't see any CORS related issues, which you
currently have. And also you won't need to solve things like
refreshing tokens etc. as this is done automatically by adapter of JEE frontend
application. So that's my suggestion.
Marek
On 15.4.2014 01:43, Davide Ungari wrote:
Hi Bill,
it's a mixed approach, maybe this is confusing you.
> I don't understand what the flow is below. In your flow above you said
> your server is making a call to the backend service with the token and
> is authenticated correctly, right?
My frontend is a WAR running on Tomcat and it is secured by keycloak.
> What I don't understand is what you are doing below. Are you saying you
> have a Browser client (Javascript) making a call to your backend?
The WAR serves also an AngularJS dashboard, in this dashboard I "inject" the
token from the server but then I make client side calls.
The flow is:
1- The user call http://.../dashboard
2- Thefrontendserver redirects to the keycloak login
3- Keycloak authenticates the user and redirects to frontendserver
4- The frontend server serves the AngularJS dashboard injecting the token
5- The client side dashboard makes ajax calls to the backend to load data
At point 5 I see my backend is logging that the call is AUTHENTICATED but on client side
I see the response is failing.
--
Davide
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:51 a.m.
New subject: How to secure JAX-RS service based on reasteasy running on undertow
Hi Marek,
I started thinking to a public REST API because I want to offer this
service also to third parties, but I see your point.
I must organize in a different way the authentication of my frontend and
then the authentication of third parties.
Thank for your suggestions are very welcome.
--
Davide
On Tue, Apr 15, 2014 at 11:28 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
Hi Davide,
I would suggest to change your flow a bit. You have frontend JEE servlet
application, which is authenticated with Keycloak. So I think that you
don't need any Keycloak accessTokens to be shared with your AngularJS
dashboard at all. I would suggest that your AngularJS dashboard won't
communicate directly with your JAX-RS backend application, but instead it
will communicate just with your servlet JEE application, which will then
re-send request to JAX-RS application with the usage of
KeycloakSecurityContext as shown in the customer-portal example. So
assuming that your frontend application is on
"http://localhost:8080/frontend" <http://localhost:8080/frontend> and
your JAX-RS is at
"http://localhost:8080/backend"<http://localhost:8080/backend>you can do:
1- The user call http://.../frontend
2- The frontend server redirects to the keycloak login
3- Keycloak authenticates the user and redirects to frontend server
4- The frontend server serves the AngularJS dashboard but NOT injecting the token (So
angularJS and your browser don't have direct access to token at all)
5- User clicks to something in AngularJS app, which will send request to
http://localhost:8080/frontend/someEndpoint
6- Frontend will re-send this to http://localhost:8080/backend/someBackendEndpoint
similarly as shown in examples, which will ensure that frontend application will attach
Bearer token to the request
7- After backend request is done and received in "frontend" app, it will resend
it back to AngularJS with all the data.
So your frontend app will be defacto proxy between AngularJS and "backend"
JAX-RS application. With this design, you won't see any CORS related issues, which you
currently have. And also you won't need to solve things like
refreshing tokens etc. as this is done automatically by adapter of JEE frontend
application. So that's my suggestion.
Marek
On 15.4.2014 01:43, Davide Ungari wrote:
Hi Bill,it's a mixed approach, maybe this is confusing you.
> I don't understand what the flow is below. In your flow above you said
> your server is making a call to the backend service with the token and
> is authenticated correctly, right?
My frontend is a WAR running on Tomcat and it is secured by keycloak.
> What I don't understand is what you are doing below. Are you saying you >
have a Browser client (Javascript) making a call to your backend?
The WAR serves also an AngularJS dashboard, in this dashboard I "inject" the
token from the server but then I make client side calls.
The flow is:
1- The user call http://.../dashboard
2- The frontend server redirects to the keycloak login
3- Keycloak authenticates the user and redirects to frontend server
4- The frontend server serves the AngularJS dashboard injecting the token
5- The client side dashboard makes ajax calls to the backend to load data
At point 5 I see my backend is logging that the call is AUTHENTICATED but on client side
I see the response is failing.
--
Davide
_______________________________________________
keycloak-user mailing
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
4:08 p.m.
New subject: How to secure JAX-RS service based on reasteasy running on undertow
We do support CORS, you just have to enable it at the adapter level and
set up the allowed origins for each application in the management console.
On 4/15/2014 5:51 AM, Davide Ungari wrote:
Hi Marek,
I started thinking to a public REST API because I want to offer this
service also to third parties, but I see your point.
I must organize in a different way the authentication of my frontend and
then the authentication of third parties.
Thank for your suggestions are very welcome.
--
Davide
On Tue, Apr 15, 2014 at 11:28 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Hi Davide,
I would suggest to change your flow a bit. You have frontend JEE
servlet application, which is authenticated with Keycloak. So I
think that you don't need any Keycloak accessTokens to be shared
with your AngularJS dashboard at all. I would suggest that your
AngularJS dashboard won't communicate directly with your JAX-RS
backend application, but instead it will communicate just with your
servlet JEE application, which will then re-send request to JAX-RS
application with the usage of KeycloakSecurityContext as shown in
the customer-portal example. So assuming that your frontend
application is on
"http://localhost:8080/frontend" <http://localhost:8080/frontend>
and your JAX-RS is at "http://localhost:8080/backend"
<http://localhost:8080/backend> you can do:
1- The user callhttp://.../frontend
2- Thefrontendserver redirects to the keycloak login
3- Keycloak authenticates the user and redirects to frontendserver
4- The frontend server serves the AngularJS dashboard but NOT injecting the token (So
angularJS and your browser don't have direct access to token at all)
5- User clicks to something in AngularJS app, which will send request
tohttp://localhost:8080/frontend/someEndpoint
6- Frontend will re-send this tohttp://localhost:8080/backend/someBackendEndpoint
similarly as shown in examples, which will ensure that frontend application will attach
Bearer token to the request
7- After backend request is done and received in "frontend" app, it will
resend it back to AngularJS with all the data.
So your frontend app will be defacto proxy between AngularJS and "backend"
JAX-RS application. With this design, you won't see any CORS related issues, which you
currently have. And also you won't need to solve things like
refreshing tokens etc. as this is done automatically by adapter of JEE frontend
application. So that's my suggestion.
Marek
On 15.4.2014 01:43, Davide Ungari wrote:
> Hi Bill,
> it's a mixed approach, maybe this is confusing you.
> > I don't understand what the flow is below. In your flow above you said
> > your server is making a call to the backend service with the token and
> > is authenticated correctly, right?
> My frontend is a WAR running on Tomcat and it is secured by keycloak.
> > What I don't understand is what you are doing below. Are you saying
you
> > have a Browser client (Javascript) making a call to your backend?
> The WAR serves also an AngularJS dashboard, in this dashboard I
"inject" the token from the server but then I make client side calls.
> The flow is:
> 1- The user callhttp://.../dashboard
> 2- Thefrontendserver redirects to the keycloak login
> 3- Keycloak authenticates the user and redirects to frontendserver
> 4- The frontend server serves the AngularJS dashboard injecting the token
> 5- The client side dashboard makes ajax calls to the backend to load data
> At point 5 I see my backend is logging that the call is AUTHENTICATED but on
client side I see the response is failing.
> --
> Davide
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:12 p.m.
New subject: How to secure JAX-RS service based on reasteasy running on undertow
Hi Marek,
I did the proxy as suggested by you.
Now I'm another step forward the authentication works but non the
authorization.
I will open another thread.
Thanks.
--
Davide
On Tue, Apr 15, 2014 at 11:51 AM, Davide Ungari <ungarida(a)gmail.com> wrote:
Hi Marek,
I started thinking to a public REST API because I want to offer this
service also to third parties, but I see your point.
I must organize in a different way the authentication of my frontend and
then the authentication of third parties.
Thank for your suggestions are very welcome.
--
Davide
On Tue, Apr 15, 2014 at 11:28 AM, Marek Posolda <mposolda(a)redhat.com>wrote:
> Hi Davide,
>
> I would suggest to change your flow a bit. You have frontend JEE servlet
> application, which is authenticated with Keycloak. So I think that you
> don't need any Keycloak accessTokens to be shared with your AngularJS
> dashboard at all. I would suggest that your AngularJS dashboard won't
> communicate directly with your JAX-RS backend application, but instead it
> will communicate just with your servlet JEE application, which will then
> re-send request to JAX-RS application with the usage of
> KeycloakSecurityContext as shown in the customer-portal example. So
> assuming that your frontend application is on
> "http://localhost:8080/frontend" <http://localhost:8080/frontend>
and
> your JAX-RS is at
"http://localhost:8080/backend"<http://localhost:8080/backend>you can do:
>
> 1- The user call http://.../frontend
>
> 2- The frontend server redirects to the keycloak login
>
> 3- Keycloak authenticates the user and redirects to frontend server
>
> 4- The frontend server serves the AngularJS dashboard but NOT injecting the token (So
angularJS and your browser don't have direct access to token at all)
>
> 5- User clicks to something in AngularJS app, which will send request to
http://localhost:8080/frontend/someEndpoint
>
> 6- Frontend will re-send this to http://localhost:8080/backend/someBackendEndpoint
similarly as shown in examples, which will ensure that frontend application will attach
Bearer token to the request
>
> 7- After backend request is done and received in "frontend" app, it will
resend it back to AngularJS with all the data.
>
> So your frontend app will be defacto proxy between AngularJS and "backend"
JAX-RS application. With this design, you won't see any CORS related issues, which you
currently have. And also you won't need to solve things like
> refreshing tokens etc. as this is done automatically by adapter of JEE frontend
application. So that's my suggestion.
>
> Marek
>
>
>
> On 15.4.2014 01:43, Davide Ungari wrote:
>
> Hi Bill,it's a mixed approach, maybe this is confusing you.
>
> > I don't understand what the flow is below. In your flow above you said
> > your server is making a call to the backend service with the token and
> > is authenticated correctly, right?
>
> My frontend is a WAR running on Tomcat and it is secured by keycloak.
>
> > What I don't understand is what you are doing below. Are you saying you
> have a Browser client (Javascript) making a call to your backend?
>
> The WAR serves also an AngularJS dashboard, in this dashboard I "inject"
the token from the server but then I make client side calls.
>
> The flow is:
>
> 1- The user call http://.../dashboard
>
> 2- The frontend server redirects to the keycloak login
>
> 3- Keycloak authenticates the user and redirects to frontend server
>
> 4- The frontend server serves the AngularJS dashboard injecting the token
>
> 5- The client side dashboard makes ajax calls to the backend to load data
>
> At point 5 I see my backend is logging that the call is AUTHENTICATED but on client
side I see the response is failing.
>
> --
> Davide
>
>
> _______________________________________________
> keycloak-user mailing
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
3664
days inactive
3673
days old
4 comments
3 participants
participants (3)
-
Bill Burke -
Davide Ungari -
Marek Posolda