Strange behaviour of dsameuser SSO token management when using ssoadm

WrenSecurity / wrenam

Community fork of OpenAM, an authentication and authorization system originally developed by ForgeRock.

Other

43 stars 27 forks source link

Strange behaviour of dsameuser SSO token management when using ssoadm #141

Open karelmaxa opened 1 year ago

karelmaxa commented 1 year ago

Currently, every ssoadm operation performed by the amAdmin account creates two SSO tokens (amAdmin, dsameuser). The token for amAdmin is destroyed when the operation is finished CommandManager.java#L215, but the dsameuser token is not. These tokens are created as non-expiring, so the AM extends their validity until the shutdown, even though they are useless. In my opinion, these tokens should also be destroyed (or not created) because there is no use case for reusing them.

pavelhoral commented 1 year ago

There are more issues related to admin tokens... The latest issue was solved in #63, although my comment contained incorrect observation that admin tokens should not belong to CTS (storing admin tokens in CTS was a planned change for AM 14).

There are few points that needs to be addressed:

SSO Administration Tool (ssoadm) has to properly destroy its tokens - this is apparently not happening.
I am not sure if ssoadm really has to create a separate session for dsameuser (as stated in the original issue description).
It really does not make sense for AM server to manage admin token expiration for tokens that are created by a different process.