I have a monitoring environment with 120 software services splitted by 4 AMD;
each software service is monitoring applications accessed via SSO;
one of this 120 software services is SSO, that is monitoring SSO layer;
looking at SSO user names, I can correctly see authenticated users, as expected;
the SSO phase creates, for each authenticated user, a cookie session called "ObSSOCookie", and I can see it exists on the login phase of each monitored applications;
each software service is configured to follow user name recognition, using the same user name & session ID rules used to recognize users in software service "SSO", but I can't see the user names.
My question is:
focusing on user name recognition, what happens if a client will navigate on applications "A", "B" and then "C"?
I mean, I have no software service to monitor application "B", so I'll be able to follow the user session through apps "A", "B" and "C", or the user session will be lost when user navigates on the not monitored "B"?
Thanks in advance for your replies
We support recognizing SSO users under the following circumstances:
So the only requirement is the same value of the cookie across SSes, the rest is configurable.
No, having same value (not name) of the cookie between the SSes is the requirement. Otherwise it won't work.
If it happens (loosing the value) within the same SS, user name will not be propagated to next operations.
I'm not sure if I understand correctly, so please let me have a quick example, just to be sure of my understanding (and my knowledge):
session id is a dynamic value, mantained by a cookie; each time it needs to change (for security reasons), the user receives a "set cookie" directive from the web app and this new value overrides the old one.
In this case, as far as I know, the AMD is able to catch this operation to override the sesion id, following user session after this change. Am I correct or wrong?
What I meant was that AMD expects cookie value that we use as a session identifier to stay the same as long as particular user is logged in as it's representation of it's session.
Thus no matter if it's the same SS or SSO support between different SSes the session identifier value must stay the same as long as user is logged in.
Please let us know if that is clear.
In the specific case mentioned, where the user session has to pass from Application A to B to C: User Name recognition and the session is kept by the HTTP decode, therefore all the Apps have to have a user defined software service configured with the same user recognition rule applied. If one App (or better, an auto discovered Software Service, in this case the "B") does not pertain to a user defined software service, the previously identified user which lands on this auto discovered software service cannot be followed.
More in general:
Session id (Cookie value)
change is supported by http decode: Lets look at 2 scenarios
In this case since the previous session id is available in the request
the HTTP decode is able to propagate the user name to the new value (in the
Both features work together automatically without any special
All the conversation must be "seen" by the same AMD.
Thank you Roberto,
in my specific case, we can't recognize user name, due to a product limitation (unresolved case: https://support.dynatrace.com/supportportal/browse/SUPDCRUM-13829), which is due to the SSO monitored by an AMD other than the AMD that monitors the application (please, see AND VOTE 🙂 my RFE@https://answers.dynatrace.com/idea/157378/rfe-sso-and-user-recognition-on-multiple-amds.html).