Single Sign Off?

[Former Member]

Hi all

I'm running the WAS 6.40 SP5 + EP 6 SP4 preview.

I have an EAR running in the J2EE Engine.

I have a servlet filter able to call UMFactory.getAuthenticator().forceLoggedInUser(), and I successfully can obtain an IUser.

My problem is single sign off. I navigate to the EP front page /irj, and then click "Log off" there. The next time I visit my own application and hit the filter, forceLoggedInUser() returns the previously logged in user -- not null. The MYSAPSSO2 cookie is now set to the empty string, whereas when the user was logged in it was non-empty. Could forceLoggedInUser() be looking in some private session state to retrieve the user rather than using the cookie?

Thanks in advance if you can straighten me out.

Hugh

If my own code calls UMFactory.getAuthenticator().forceLoggedInUser(), then when I navigate to the front page of either my application or of the EP, I am presented with a login page

[oliver_nocon]

Hi,

have you tried to log the user out using forceLogoffUser()?

I guess your problem is that you still have the jsession. This is sufficient for your ume application but not for the EP. This would explain the behaviour you describe.

It is now possible to call a specific page for additional logout procedures when you logoff from the portal. You can find details (releases, ...) in SAP Note 696294.

You have two additional parameters:

- ume.logoff.redirect.url

- ume.logoff.redirect.silent

You could redirect to a servlet which kills the session or just to an html page where the jsession is deleted.

Best regards,

Oliver

[Former Member]

Hi Oliver, thanks for your reply.

Well you see the point is not to log off the user if he hasn't logged off in the portal! Yes, certainly if I call forceLogoffUser, the next time I call forceLogonUser, it returns null IUser and navigates him to the logon page.

The problem is that the SAPSSO2 cookie value has changed, yet forceLogonUser returns the cached user still in the session. I would say that is not expected behavior. I would expect the api to return the authenticated, new user in the cookie over the stale one in the session. Then I, the caller of the api, would see that the portal user has changed, and could invalidate the session. As it stands using the api, I can never determine that the user has changed.

My workaround is this: I cache the cookie value in the session myself. If the cookie value changes, I invalidate the session and call forceLogonUser, which then correctly returns the new IUser (or null if he has logged out but not logged in again under a new identity).

Regards

Hugh

[oliver_nocon]

Hi Hugh,

wouldn't it help if you make sure that the user logged out completely from the portal.

-> JSession killed

As I understand your scenario the users first log off from the portal before they hit your application.

Best regards,

Oliver

[Former Member]

Hi

I've been looking your posts about the use of the "ume.logoff.redirect.url" propertie and I have writed the url as the document expained but it doesnu00B4t work, neither restarting the server.

Could you help me please because I don't understand how it really works, because I was looking at the file in "\j2ee\j2ee_00\ume" and I only found a file called "sapum.properties.bak" that does not contains the changes, so I did it from the portal and I don't know then where it is saved my changes.

Greetings!!

[Former Member]

It saves the changes in PCD, which is in the portal database. (and not on the file system anymore)

Don't know why it doesn't work for you

Message was edited by: Dagfinn Parnas