Christophe Cariou 5 Months Ago - Edited Great coincidence Dave... exactly the subject I'm working on in my new company ! I have an ask on openId subject for you or Fabian (but perhaps should I post it on slack). What will be the better approach on Single Log Out, dealing with different situations as : - logout from frontend => send message to the provider to propagate other app client sessions - timed out session (or killed session) on portal side => send message to the provider to close session token on its side - logout received from provider, on client session ended (triggerred by an other app) My provider is KeyCloak. Please sign in to reply. Reply as... Cancel David H Nebinger Christophe Cariou 5 Months Ago - Edited IMHO, SLO is hard (conceptually). When I use SSO to log into liferay.dev, as an employee I'm also signing in for our ticketing system, our customer download area, the Liferay Marketplace, plus a number of other resources. I'm typically not _purposefully_ logging into those other systems, i.e. I'm lucky if I go to the marketplace site once a quarter or something, but when I land there and I don't have to log in, it's quite convenient. If I wanted to log out of liferay.dev, as a user conceptually I'm only thinking about logging out of liferay.dev, not all of the other systems, but with SLO even though I'm only thinking about logging out of one, I've now logged out of the others. Once I've logged out of one and, because of SLO, I'm logged out of the others, if I then flipped over to our ticketing system, I have to log in. Now SLO is actually _inconvenient_ for me because I didn't actually log out of the ticketing system, SLO did. So as a user, now, I don't log out at all, because a SLO logout is not anything that I want to deal with. Obviously my sessions will expire across a number of the systems, but because I'm staying in other Liferay systems all day, my SSO tokens are good and if I go back to liferay.dev after some delay I get auto-logged back in. So as a _user_, I don't want SLO at all. Now, from a business perspective, though, there's a different argument to make, right? Because of security, I want SLO because if a user chooses to log out, I want their sessions killed on all of the apps they might be using and hey, if they need to re-log back in to access one of the other systems, that is still safer than just letting the SSO token live all day. But still I can be foiled when the users stop logging out because they don't like the inconvenience of re-authenticating. And as long as they stay active in at least one of the systems I'm protecting with SSO, their token has to remain valid. No matter what I want to do as an admin from a SLO perspective, it only will matter if the users actually log out... Now I'm sure I haven't answered your question, but if I were to, it would probably be something along the lines of "it depends upon what your requirements dictate". But hopefully I've given you something to chew upon? Please sign in to reply. Reply as... Cancel Christophe Cariou David H Nebinger 5 Months Ago - Edited Hi Dave and thank you for giving your point of view with arguments. I'm agree with you : personally, I prefer to choose when I log out (and even "on") from any system. But my ask was from a business need, when end users came to portal and then access by a link to an other system, under the same IAM. In this case, they don't need/want to log in again. And then a logout from the portal or even from the linked system should be propagated (by security design). But your answer make me think that I should first address User Experience and journey before deeping in technical answer. So, i'm going on chewing a little more until I came to a perfect bubble gum... Please sign in to reply. Reply as... Cancel Christoph Rabel Christophe Cariou 5 Months Ago - Edited We use a reverse proxy mod_auth_openidc + a custom header based login module for that. mod_auth_openidc supports backchannel logout quite well and configuration is rather easy. It also works quite well with Keycloak. The custom module we have implemented (alas, for a customer, so I can't really open source it) basically works the same as the RequestHeaderAutoLogin module. It reads the oidc headers that mod_auth_openidc sets and creates/updates the user. https://github.com/liferay/liferay-portal/blob/master/modules/apps/portal-security/portal-security-auto-login/src/main/java/com/liferay/portal/security/auto/login/request/header/RequestHeaderAutoLogin.java We also have a filter that: - Stores the oidcUsername in the session - Compares the stored username in the session with the headers - If it doesn't match, invalidates the session That way we enforce that the user in Liferay always matches the user from the reverse proxy. I couldn't find an example for that in the Liferay code, but at least some (older?) Liferay versions also had such a filter. Please sign in to reply. Reply as... Cancel
David H Nebinger Christophe Cariou 5 Months Ago - Edited IMHO, SLO is hard (conceptually). When I use SSO to log into liferay.dev, as an employee I'm also signing in for our ticketing system, our customer download area, the Liferay Marketplace, plus a number of other resources. I'm typically not _purposefully_ logging into those other systems, i.e. I'm lucky if I go to the marketplace site once a quarter or something, but when I land there and I don't have to log in, it's quite convenient. If I wanted to log out of liferay.dev, as a user conceptually I'm only thinking about logging out of liferay.dev, not all of the other systems, but with SLO even though I'm only thinking about logging out of one, I've now logged out of the others. Once I've logged out of one and, because of SLO, I'm logged out of the others, if I then flipped over to our ticketing system, I have to log in. Now SLO is actually _inconvenient_ for me because I didn't actually log out of the ticketing system, SLO did. So as a user, now, I don't log out at all, because a SLO logout is not anything that I want to deal with. Obviously my sessions will expire across a number of the systems, but because I'm staying in other Liferay systems all day, my SSO tokens are good and if I go back to liferay.dev after some delay I get auto-logged back in. So as a _user_, I don't want SLO at all. Now, from a business perspective, though, there's a different argument to make, right? Because of security, I want SLO because if a user chooses to log out, I want their sessions killed on all of the apps they might be using and hey, if they need to re-log back in to access one of the other systems, that is still safer than just letting the SSO token live all day. But still I can be foiled when the users stop logging out because they don't like the inconvenience of re-authenticating. And as long as they stay active in at least one of the systems I'm protecting with SSO, their token has to remain valid. No matter what I want to do as an admin from a SLO perspective, it only will matter if the users actually log out... Now I'm sure I haven't answered your question, but if I were to, it would probably be something along the lines of "it depends upon what your requirements dictate". But hopefully I've given you something to chew upon? Please sign in to reply. Reply as... Cancel Christophe Cariou David H Nebinger 5 Months Ago - Edited Hi Dave and thank you for giving your point of view with arguments. I'm agree with you : personally, I prefer to choose when I log out (and even "on") from any system. But my ask was from a business need, when end users came to portal and then access by a link to an other system, under the same IAM. In this case, they don't need/want to log in again. And then a logout from the portal or even from the linked system should be propagated (by security design). But your answer make me think that I should first address User Experience and journey before deeping in technical answer. So, i'm going on chewing a little more until I came to a perfect bubble gum... Please sign in to reply. Reply as... Cancel
Christophe Cariou David H Nebinger 5 Months Ago - Edited Hi Dave and thank you for giving your point of view with arguments. I'm agree with you : personally, I prefer to choose when I log out (and even "on") from any system. But my ask was from a business need, when end users came to portal and then access by a link to an other system, under the same IAM. In this case, they don't need/want to log in again. And then a logout from the portal or even from the linked system should be propagated (by security design). But your answer make me think that I should first address User Experience and journey before deeping in technical answer. So, i'm going on chewing a little more until I came to a perfect bubble gum... Please sign in to reply. Reply as... Cancel
Christoph Rabel Christophe Cariou 5 Months Ago - Edited We use a reverse proxy mod_auth_openidc + a custom header based login module for that. mod_auth_openidc supports backchannel logout quite well and configuration is rather easy. It also works quite well with Keycloak. The custom module we have implemented (alas, for a customer, so I can't really open source it) basically works the same as the RequestHeaderAutoLogin module. It reads the oidc headers that mod_auth_openidc sets and creates/updates the user. https://github.com/liferay/liferay-portal/blob/master/modules/apps/portal-security/portal-security-auto-login/src/main/java/com/liferay/portal/security/auto/login/request/header/RequestHeaderAutoLogin.java We also have a filter that: - Stores the oidcUsername in the session - Compares the stored username in the session with the headers - If it doesn't match, invalidates the session That way we enforce that the user in Liferay always matches the user from the reverse proxy. I couldn't find an example for that in the Liferay code, but at least some (older?) Liferay versions also had such a filter. Please sign in to reply. Reply as... Cancel
Jan Verweij 9 Days Ago - Edited Great Info @David and @Fabian. In fact I run into an issue where userinfo needs to be updated. New employees are registered initially in the IDP with their personal email address to start the onboarding. They login to Liferay and all works fine. Now their email address is updated to the company email and all of a sudden they can't login in any more. Currently removing their user account from Liferay fixes the problem, but probably updating their email address would solve it on the fly. Please sign in to reply. Reply as... Cancel