cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

sso and user recognition

p_esposito
Guide

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:

  • assumption 1: I have 3 applications, called "A", "B" and "C", accessed via "SSO";
  • assumption 2: I created 3 software services, to monitor "SSO", "A" and "C", using user name recognition

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

P

7 REPLIES 7

adam_piotrowicz
Dynatrace Pro
Dynatrace Pro

We support recognizing SSO users under the following circumstances:


  1. One SS extracts user and associates it with cookie,
  2. The other must have:

    1. The same name of the policy (in RUM Console),
    2. May have different cookie name,
    3. Must have the same value of configured cookie as the SS from where user originally comes from.

So the only requirement is the same value of the cookie across SSes, the rest is configurable.

Hi Adam, I noticed sometime that the cookie value changes, even within the same SS (send cookie --> receive cookie: I remember DCRUM handling this within SSO. still true?

Thanks Roberto

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?

Thank you

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.

Roberto_Vannucc
Dynatrace Organizer
Dynatrace Organizer

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


  • 1. Cookie value change (ad example siteminder SSO) – the server periodically changes the value of session id cookie
    sending “set-cookie” in the response.

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
response).


  • 2. Separate
    authentication server is used – the authentication is done on one server (the
    AMD learns about the link between user name and session id) and then there is a
    redirect to the second server application server. The user name is propagated
    to the second server only if the same “user recognition policy” is used /
    defined on both servers and the value of session id is the same. However the
    actual name of the cookie could be different on both servers.

Both features work together automatically without any special
configuration.

All the conversation must be "seen" by the same AMD.

Regards. Roberto

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).

Regards

Pasquale