[ https://jira.jboss.org/jira/browse/GTNPORTAL-1048?page=com.atlassian.jira... ] Marek Posolda updated GTNPORTAL-1048: ------------------------------------- Attachment: identityException-createCriteria.txt identityException-screenshot.png -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/GTNPORTAL-1048?page=com.atlassian.jira... ] Sohil Shah commented on GTNPORTAL-1048: --------------------------------------- ok so after running lots of scenarios and debugging here is what I have found out: The core issue probably lies inside PicketLink or the exo identity components that integrate with it. This issue affects all SSO frameworks, not just OpenSSO. I have can replicate this issue "intermittently" with CAS and the newly added member SPNEGO. Here is an explanation of what is going on. The SSOLoginModules by design do not deal with a password. They deal with a trust token for each framework, making a trust call back from GateIn, and then establishing an authenticated Identity based on that trust. The problem lies with the fact that, if a "password" based validation is not performed inside the LoginModule, looks like the PicketLink Cache is out of sync with the authenticated state of the session. When I add the following lines of code to the SSOLoginModule, everything works fine consistently: Credential[] credentials = new Credential[]{new UsernameCredential(username), new PasswordCredential("gtn")}; String userId = authenticator.validateUser(credentials); This is obviously for testing only. In SSO context, this does not make sense since its a password-less authentication. The only code that should suffice for SSO is: Identity identity = authenticator.createIdentity(username); since the password input/validation is performed at the SSO framework's authentication server. Bolek- I hope this is enough narrowed down information to investigate deeper into why the PL Cache Layer is out of sync. btw- I did try the SPENGOFilter hack with OpenSSO and CAS, but those two did not work at all. For some reason the Filter creating a TX context works for SPNEGO, but I seriously think its not the right solution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/GTNPORTAL-1048?page=com.atlassian.jira... ] Boleslaw Dawidowicz commented on GTNPORTAL-1048: ------------------------------------------------ It is not PL issue as the exception is not related to any PL internal cache or even identity component cache but gatein filter performing IDM call outside of valid transaction. And no hibernate object is passed outside picketlink in any situation so there is nothing to get out of sync really... this is not PL Cache Layer. So if this can be observed in every type of SSO integration this means that something seriously differs in the flow there. Anyway I'll followup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/GTNPORTAL-1048?page=com.atlassian.jira... ] Boleslaw Dawidowicz commented on GTNPORTAL-1048: ------------------------------------------------ Yes, thats the point. As IDM call in authenticator is wrap with the call to begin/end in proper ComponentRequestLifecycle. Then by establishing identity SSO integration makes SetCurrentIdentityFilter to create new ConversationState which then make CacheUserProfileFilter to call IDM to cache user profile. I'll try to come with workaround that will work in both configurations (with or without SSO). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/GTNPORTAL-1048?page=com.atlassian.jira... ] Thomas Heute updated GTNPORTAL-1048: ------------------------------------ Fix Version/s: 3.1.0-GA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira