<div dir="ltr">If we make it pluggable do we even need to support non-KC IDPs? End of the day we're focusing on KC right and users can implement their own for other IDPs.</div><div class="gmail_extra"><br><div class="gmail_quote">On 15 September 2015 at 15:39, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yeah, of course it would be pluggable. I don't want to force people to use a distributed cache. :)<br>
<br>
Another idea, if we don't want to ship infinispan with our SAML/OIDC SP is to provide a list of nodes in the adapter config. When a SSO session is started, store the information in memory. When logout, query other machines until you find who stores the SSO sesion->local sessionid mapping.<span class=""><br>
<br>
On 9/15/2015 9:23 AM, Stian Thorgersen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Oh, I turned things around - I thought it was the SSO session id that<br>
was missing, not the http session id. Ignore everything I've said up<br>
until now ;)<br>
<br>
Maybe we could make the SSO Session ID --> HTTP Session ID map pluggable<br>
then? By default it would use the mechanism Marek implemented, but then<br>
we can support other means as well?<br>
<br>
On 15 September 2015 at 15:14, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br></span><span class="">
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>> wrote:<br>
<br>
no. The session id sent with the logout request is the SSO session<br>
id. The client does not transmit its session id to the IdP.<br>
<br>
On 9/15/2015 9:04 AM, Stian Thorgersen wrote:<br>
<br>
Isn't the http session id part of the standard backchannel log out?<br>
<br>
On 15 September 2015 at 14:58, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>><br></span><div><div class="h5">
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>>> wrote:<br>
<br>
We can do anything we want on the server side, the problem<br>
is that<br>
our client adapters, SAML and OIDC, should be able to work with<br>
non-Keycloak IdPs.<br>
<br>
On 9/15/2015 7:25 AM, Stian Thorgersen wrote:<br>
<br>
Could we store the mapping on the Keycloak side?<br>
client-id + http<br>
session id --> KC session id?<br>
<br>
On 14 September 2015 at 22:41, Bill Burke<br>
<<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>><br>
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>><br>
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>><br>
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>>>> wrote:<br>
<br>
<br>
<br>
On 9/14/2015 4:20 PM, Marek Posolda wrote:<br>
> On 14/09/15 21:46, Bill Burke wrote:<br>
>> The SAML IdP is not required to send back that<br>
id. That<br>
ID is just<br>
>> the ID of the request.<br>
> The SAML IdP doesn't need to send anything back.<br>
I meant that<br>
> HttpSessionID will be send in the ID of<br>
SAMLRequest from<br>
SAML SP to<br>
> auth-server . I don't know if there is any better<br>
attribute/element of<br>
> AuthnRequest, which can be used to transmit such<br>
"custom"<br>
data.<br>
><br>
<br>
SAML logout requests to the SP client contain the<br>
principal<br>
name and/or<br>
possibly one *or more* SSO IDs (session indexes).<br>
New OIDC<br>
spec will<br>
work similarly.<br>
<br>
>><br>
>> A hack I'm thinking of is to create an<br>
HttpSession that<br>
is shared by<br>
>> everybody and store this SSO id/username -> to -><br>
HttpSession id map<br>
>> there.<br>
> That's good, we can avoid dependency on infinispan.<br>
<br>
Ugh, unfortunately, you can't provide our own<br>
session id<br>
with Undertow's<br>
or Jetty's sessionmanager interface. :( So no way<br>
to hack<br>
this except<br>
for Tomcat and JbossWeb.<br>
<br>
> But still, we will<br>
> need the stuff like periodic cleaner thread,<br>
which will<br>
remove expired<br>
> items from this HttpSession map. And this solution<br>
requires HttpSession<br>
> replication if I understand correctly?<br>
><br>
<br>
Replication would be required, but all these servlet<br>
containers contain<br>
session lifecycle listener SPIs, so there is no<br>
need for<br>
reaper threads.<br>
But, can't do it anyways...<br>
<br>
> As of now, we don't require HttpSession<br>
replication for<br>
OIDC. Qe support<br>
> the deployments when the application is deployed<br>
on more<br>
"cluster" nodes<br>
> behind loadbalancer, but application cluster<br>
nodes don't<br>
communicate<br>
> with each other. In other words, there is no<br>
"distributable" in web.xml<br>
> . For this case, we have CLIENT_SESSION_HOST<br>
note, so the<br>
OIDC<br>
> backchannel request is sent to same cluster node<br>
from<br>
which was<br>
> code-to-token request sent earlier.<br>
><br>
<br>
Again, not something we can implement in a<br>
standard/portable way.<br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a> <mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>>><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>>>><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
<br>
<br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
<br>
<br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
<br>
<br>
</div></div></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
</div></div></blockquote></div><br></div>