[keycloak-user] OIDCFilterSessionStore

[Mohan.Radhakrishnan at cognizant.com]

Earlier we weren't using sessions because our application on Azure had to scale out. So all the requests had to contain an access token so that which node handles those was immaterial. But stateful ecommerce sites may not work with this approach. I think that is what you mean. But this is Rest with sessions ? We had GUID generators to identify the user which was part of the claim.

I used the Implicit flow with an access token issued with an ID token. The client was AngularJS. What is the equivalent configuration for this ?

Now I use this. The response type should be access token ? But that type is not accepted. So I am doing something wrong.

http://localhost:8080/auth/realms/Pearson/protocol/openid-connect/auth?response_type=id_token&redirect_uri=http://localhost:8000/keycloak/claim/&realm=Pearson&client_id=Pearson&scope=user

Moreover the filter validates by contacting the server but I need to introspect and get the claims for the business process.

Thanks,
Mohan
________________________________
From: Scott Rossillo [srossillo at smartling.com]
Sent: Saturday, July 30, 2016 2:27 AM
To: Radhakrishnan, Mohan (Cognizant)
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] OIDCFilterSessionStore

For your first question, with OIDC there are three types of clients: confidential, public and bearer-only. For simplicity, let’s consider confidential, public as applications that you log into, for example, an e-commerce website. These applications have a session which stores the access token, ID token, and refresh token. When a request comes into the website the application, the session ID is used to establish who you are. This could mean making your OIDC tokens accessible to server side code.

A bearer-only application does not use sessions. It expects the OIDC access token to be sent in the authorization HTTP header on every request. It is a stateless application. Continuing your example, let’s say your e-commerce website needs to call a service that provides up to date inventory information when a user adds an item to cart. This can be a stateless service but wants to know what user is requesting inventory. The e-commerce website could retrieve the access token from the session and query the bearer-only application.

This is just one example, and a bit of an oversimplification of the things a confidential and public client can do. However, the point I’m trying to make is that by defining a client as bearer-only you are essentially saying it’s a stateless service that requires an OIDC access token on every request.

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com<redir.aspx?REF=j6dPT32YTAtd3OSXUceWIesC4Z0rWEwRl4cn2OAlq5GtXKWOgbjTCAFtYWlsdG86c3Jvc3NpbGxvQHNtYXJ0bGluZy5jb20.>

On Jul 29, 2016, at 9:18 AM, Mohan.Radhakrishnan at cognizant.com<redir.aspx?REF=-W95hPM06aEOGa4PPERHiMKHbaBCpuH6Gz8eh78BrhUQvqeOgbjTCAFtYWlsdG86TW9oYW4uUmFkaGFrcmlzaG5hbkBjb2duaXphbnQuY29t> wrote:

Hi,
            I have some doubts. I am using spring boot. The servlet filter adapter actually uses sessions. Is that right ? I was thinking the token will be required for every Rest endpoint access. But unless I clear jsessionid it is not required. Have I understood this correctly ?

How do I get the claims from my implicit token ? Do I need the spring boot adapter ? Can I see an example combining implicit token and boot adapter ?

Thanks,
Mohan
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. _______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<redir.aspx?REF=xgJMBDOPiq-hT1VvSfc8rzmjnTzdMdM4kXz3U-Ezg_8QvqeOgbjTCAFtYWlsdG86a2V5Y2xvYWstdXNlckBsaXN0cy5qYm9zcy5vcmc.>
https://lists.jboss.org/mailman/listinfo/keycloak-user<redir.aspx?REF=Xdevq_aDvjYGmmY07NtoNVPhlBs9rx9A1gFtEibGMwQQvqeOgbjTCAFodHRwczovL2xpc3RzLmpib3NzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2tleWNsb2FrLXVzZXI.>

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160730/1a86dd52/attachment-0001.html