Strange behaviour of dsameuser SSO token management when using ssoadm

[karelmaxa]

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]

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.