Bug 1173313
| Summary: | JBoss Web SingleSignOn valve does not work with <distributable/> apps | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Aaron Ogburn <aogburn> | ||||
| Component: | Web | Assignee: | Rémy Maucherat <rmaucher> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Michael Cada <mcada> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.4.0 | ||||||
| Target Milestone: | ER1 | ||||||
| Target Release: | EAP 6.4.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-08-19 12:45:18 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1175139 | ||||||
| Bug Blocks: | 1175380 | ||||||
| Attachments: |
|
||||||
Created attachment 967400 [details] BZ1173313.diff I don't think we want to just have SSO ignore passivation completely. If it did, then when a session is passivated, the session would never be removed from the SSO maps, and it'd not be released from heap. That'd make passivation pretty pointless so I think we should just have SSO ignore passivation events caused by replication. Here's a simple PR that will indicate through the SessionEvent details that replication is the cause: PR: https://github.com/jbossas/jboss-eap/pull/2152 And BZ1173313.diff is a diff of changes needed to JBossWeb so that SSO ignores said replication triggered passivation events. Does this look like a good solution? With the clustered configuration, aren't you supposed to use the Clustered SSO valve as well ? In the reproducer, JBoss actually isn't clustered and is running entirely without jgroups. The only thing really related to clustering in the configuration is the <distributable/> flag in the app web.xml. In some cases, that config just comes fresh out the box for third party apps used by customers on JBoss, leading to this issue if they're trying to use that app with unclustered SSO on an unclustered JBoss instance. Maybe a larger overall concern is that the web layer bothers using DistributableSessionManager and ClusteredSessions just because <distributable/> is set even though clustering components are absent? If it didn't, then this issue would be avoided as well. And note the fix also requires a JBossWeb layer change as in the BZ1173313.diff attachment Verified with EAP 6.4.0.ER1. |
Description of problem: The JBoss Web SingleSignOn valve does not work with <distributable/> applications. Replication throws a session passivation event, so every request has the sso entry destroyed at the end at replication time. Thus when doing a logout or session invalidation, session entries tied to the SSO are not invalidated after being improperly dropped by the replication/passivation event. Version-Release number of selected component (if applicable): JBossWeb 7.5 How reproducible: Very Steps to Reproduce: 1. Use standalone-full.xml with SSO added to the web subsystem: <virtual-server name="default-host" enable-welcome-root="true"> <alias name="localhost"/> <alias name="example.com"/> <sso reauthenticate="false"/> </virtual-server> 2. Deploying the applications "afsa-sample-service.war" and "afsa-ui-jboss.war" 3. Add an application user with ./add-user.sh under the frevvo.Designer group/role. 4. Launch JBoss with java 7. 5. Go to http://localhost:8080/afsa-ui-jboss/login and login 6. Open a new tab a go to http://localhost:8080/afsa-sample-service/hello.jsp 7. Go back to the first tab and logout. 8. Log back in (as the same user or a different one it doesn't matter) 9. Go to the second tab. Take notice of the timestamp that was originally generated and displayed. Hit refresh. Notice how the timestamp doesn't change (the time is a session attribute, showing that the session wasn't invalidated after logout). Actual results: All sessions tied to an SSO entry are not invalidated upon logout or invalidation. Expected results: All sessions tied to an SSO entry are invalidated upon logout or invalidation. (But org.apache.catalina.authenticator.AuthenticatorBase.UNREGISTER_SSO_ON_LOGOUT has to be set true for SSO to cause invalidation just from request.logout()) Additional info: