-
1. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
ctomc Sep 11, 2014 6:24 AM (in response to sandeep.samdaria)That is correct behavior. Each application needs to get its own session id for their context root.
If you want both applications to have same session, then you would need not single sign on but session sharing across applications.
you can achieve that by adding jboss-all.xml to WEB-INF of both apps with content
<jboss umlns="urn:jboss:1.0">
<shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
</shared-session-config>
</jboss>
-
2. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
sandeep.samdaria Sep 11, 2014 9:36 AM (in response to ctomc)After adding jboss-all.xml to my application, I am getting the following error.
16:57:32,442 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."test1-0.1.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test1-0.1.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "test1-0.1.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018774: Error loading jboss-all.xml from /home/xxx/grails-project/wildfly-8.1.0.Final/standalone/tmp/vfs/temp/temp9db78ca7eb11ba99/test1-0.1.war-285801972c8f28e9/WEB-INF/jboss-all.xml
at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor.parse(JBossAllXMLParsingProcessor.java:153) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor.parse(JBossAllXMLParsingProcessor.java:128) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor.deploy(JBossAllXMLParsingProcessor.java:96) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
... 5 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,5]
Message: Unexpected element '{urn:jboss:shared-session-config:1.0}shared-session-config'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108)
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor$Parser.parseJBossElement(JBossAllXMLParsingProcessor.java:203) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor$Parser.readElement(JBossAllXMLParsingProcessor.java:192) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor$Parser.readElement(JBossAllXMLParsingProcessor.java:176) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.server.deployment.jbossallxml.JBossAllXMLParsingProcessor.parse(JBossAllXMLParsingProcessor.java:148) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
... 8 more
It seems that the shared-session-config schema is not available in 8.1.0.Final.
Below is my jboss-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/test1</context-root>
<!-- <security-domain>sso</security-domain> -->
</jboss-web>
jboss-all.xml
<jboss umlns="urn:jboss:1.0">
<shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
</shared-session-config>
</jboss>
-
3. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
pferraro Sep 11, 2014 1:01 PM (in response to sandeep.samdaria)1 of 1 people found this helpfulSession sharing across web applications is a new feature and is only available in the master branch, on which WF 9.0 will be based.
However, you would only need this to share session attribute data between multiple applications - not for single sign on.
-
4. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
sandeep.samdaria Sep 11, 2014 1:28 PM (in response to pferraro)I think I have misunderstood Single Sign On.
Basically what I wanted was that both the application will have the same JSESSIONID.By "share", I mean that the JSESSIONID should not change when I switch to different context . For e.g. When I visit localhost/abc, I would get JSESSIONID="ABC123" and when I visit localhost/xyz, I would get the same JSESSIONID i.e. "ABC123". In jboss-eap-6.2 this is the behavior, but in wildfly.8.1.0 when I visit localhost/xyz I get a different JSESSIONID "ZYX987" and when I revisit localhost/abc the previous session id(ABC123) is lost and I get a new id.
-
5. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
pferraro Sep 11, 2014 5:31 PM (in response to sandeep.samdaria)Why do you want both applications to use the same JSESSIONID? This sounds like a strategy, rather than a need. Do the applications need to share the same set of session attribute? If so, you need shared sessions. Do the applications need to share authentication state? If so, then you need need to enable single sign on. These are orthogonal concerns.
-
6. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
sandeep.samdaria Sep 12, 2014 1:08 AM (in response to pferraro)Once the user successfully logs in, we persist the session id along with the user details, when the user visits the other application, we retrieve the user details based on its SESSION ID. Since both the application used to have the same session id, we were able to verify the user. After migrating from jboss-4.2.3 to wildfly-8.1.0, the applications are having different session id, hence unable to verify the user. My requirement is more of shared session.
I will give 9.X a try. Few questions for the shared session. Is it necessary that both the WARs should be in a single EAR ? Will shared session work if I deploy both the WAR independently inside deployment folder? -
7. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
pferraro Sep 12, 2014 9:32 AM (in response to sandeep.samdaria)Your requirement should like the single sign on use case, and it seems as if you are trying to implement it yourself using shared sessions. Why not use the single sign on mechanism in WildFly, which does not require session sharing?
-
8. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
sandeep.samdaria Sep 12, 2014 10:49 AM (in response to pferraro)Is there any document/tutorial which I can follow to implement the same on wildfly-8.1.0 ? I am unable to find any such reference to implement single sign on.
Please correct me if I am wrong, this is what my understanding of single sign on is. If a user logs in to one application and then goes to the other application, then the app will be able to retrieve the user information.
Thanks for bearing my naive questions.
-
9. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
pferraro Sep 12, 2014 6:04 PM (in response to sandeep.samdaria)When single sign-on is configured for a given host, once a user is logged into an application, their authentication identity is shared across all applications for that host. To enable, add <single-sign-on/> to a <host/> within your undertow subsystem configuration. If your applications use different context paths, you'll need to set the cookie path for the SSO cookie accordingly, e.g. <single-sign-on path="/" />.
-
10. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
sandeep.samdaria Sep 15, 2014 3:29 AM (in response to pferraro)Few questions :
In Single Sign on, where is the authentication mechanism is to be implemented ? I have the users credential in the db, how can I configure SSO to use those credentials?How will the users information be retrieved per application ?
-
11. Re: Sharing JSESSIONID across two applications(war) in a wildfly instance
pferraro Sep 15, 2014 8:42 AM (in response to sandeep.samdaria)You'll want to implement an authentication plugin and potentially an authorization plugin. See: Security Realms - WildFly 8 - Project Documentation Editor