Consider the below scenario:
I have two publish servers to serve the requests behind the dispatcher which is performing some load-balancing mechanism distributing requests between the two servers in a round-robin fashion.
Use Case:
The user enters the login credentials from the login page and clicks 'Submit'. The dispatcher directs the request to 'Publish Server 1'. After successful authentication a session ID is provided to the client and the corresponding session information is stored on the 'Publish 1'.
The user hits another protected page but the dispatcher redirects the request to 'Publish Server 2' which doesn't have the session information corresponding to the session ID.
Plausible result: The session is reset and the user is prompted to login again.
How to handle such a requirement?
Note: My users do not reside in AEM, the authenticity of the users is being validated from a database.
P.S.: I have already been to a few blogs which say that Http Session clustering is not supported by AEM but none of them provides the correct solution to the problem.
One alternative is to use network routing. We use a load balancer, and it can be configured to enable sticky sessions. It essentially adds a cookie that is used for subsequent requests to route the user to the same publisher that the user hit the first time. This is a non-AEM solution and purely a feature of the network and load balancer, so it may or may not be an option in your case. AEM dispatcher config also allows stickyConnections configuration that sounds like would accomplish the same thing done in a network load balancer.
See also
https://docs.adobe.com/docs/en/dispatcher.html#The%20Benefits%20of%20Load%20Balancing
https://docs.adobe.com/docs/en/dispatcher/disp-config.html#par_175_73_0012
You can do the following
Enable Sticky sessions on both dispatcher and the Load Balancer (if you have one)
#Allowing Sticky sessions
/stickyConnectionsFor "/content/brand/en-us"
Enable Session Management
#Configuration to increase session timeout limit
/sessionmanagement
{
/directory "/mnt/var/www/html/content/.sessions"
/header "Cookie:login-token"
/timeout "3600"
}
PS: 3600s=60mins
Two possible solutions -
1)If external IDP provides a service for authentication, then store the authentication information in a cookie. Whichever publisher request goes to, it will use the information in cookie and will check with IDP service for session.
2) If using your custom authentication handler, then use sticky session at dispatcher, this will make sure request goes back to the same publisher where session is active.
Related
We have come across similar problem, need your help to resolve this.
Can you please either let us know your contact number so that we can reach out to you or if you can provide your script if possible so that we can refer to
Here is the problem we are stuck with:
I am trying to test a Rest service through HTTP sampler using Jmeter. Not sure how to capture token from the sampler generates a token and to use this token for authorization in the header manager of another HTTP.
Loadrunner is not displaying the web address when trying to enter in the truclient browser. Below is the problem as this web address automatically redirect to another web address which is the authentication server.
Can you please suggest another solution for the below issue?
Here is the exact scenario we are trying to achieve
we want to loadtest the portal however due to redirect and different authentication method being used we are unable to do it using truclient protocol in loadrunner. Also tried Multiple protocol selecting LDAP, SMTP, HTTP/HTML etc but no luck.**
Thank You,
Sonny
JMETER is going to architecturally be the HTTP protocol layer equivalent with LoadRunner, with the exception of the number of threads per browser emulation.
In contrast to the code request, I want to architecturally visualize the problem. You mention redirect, is this an HTTP 301/302 redirect or one which is handled with information passed back to the client, processed on the client and then redirected to another host? You mention dynamic authentication via header token, have you examined the web_add_header() and web_add_auto_header() in Laodrunner web virtual users for passing of extra header messages, including ones which have been correlated from previous requests, such as the token being passed back as you note?
This authentication mechanism is based upon? LDAP? Kerberos? Windows Integrated Authentication? Simple Authentication based upon username/password in header? Can you be architecturally more specific and when this comes into play, such as from the first request to gain access to the test environment through the firewall or from a nth request to gain access within a business process?
You mention RESTFul services. These can be transport independent, such as being passed over SMTP using a mailbox to broker the passing of data between client and server, or over HTTP similar to SOAP messages. Do you have architectural clarity on this? Could it be that you need to provide mailbox authentication across SMTP and POP3 to send and receive?
For browser based request with sticky session true load balancer can restrict request to same JVM out of multiple JVMs in a cluster.
But in case request is coming from REST client rather any browser, how the load balancer can restrict requests to same JVM even sticky session is set as true? Any Idea please.
REST client is made to call REST API and REST APIs should be stateless i.e. complete information about processing of request should be present in request itself, thus request should not dependent on any session data.
If your API is dependent on session data then in actual it is not following some principles of REST.
If your requirement is such that you need to maintain the state then it should be maintained on client side not on server. So one of the way that i will suggest is that you can use cookies to store your state and temp data. While making any REST api call just attach that cookie with request.
You can make cookie configurable so that it will be controlled by server and no one else can make change in it.
The load balancer uses Cookies to keep track of sessions. Retaining the cookies and sending them back in the client should be enough to get the expected result.
For instance, in python, that would mean replacing requests.get(url) with:
s = requests.session()
// ...
s.get(url)
I am working on a webapi project which of course is supposed to be stateless.
The point is that it requires authetication and the majority of it's services is available to logged in users.
The catch is that there are several pieces of information about that user which should be used on all subqsequent calls to the legacy backend.
Should I force the clients to send back all those parameters on each request? (doesn't seem fair)
Should I use a caching on the webapi side - this is tricky as currently there is no out-of-memory distributed cache in use in the deployment environment....
What options do you see?
You could choose to issue the user some kind of session token on the first call. The server could then use the session token to authenticate the user and remember the settings for that session on subsequent calls.
You can read more about managing sessions in a stateless environment here:
http://en.wikipedia.org/wiki/Session_management
I have a high-level/conceptual question about Shibboleth.
I'm working on the front-end (running Drupal) of a data-driven web app. End-users interact with the front-end to construct data queries, which makes background requests to a caching/archiving data proxy (the "data retrieval service"), which in turn either delivers data from its cache or goes out and queries still more services ("out there") which have desired data. So far so good... it is ornate, but only as ornate as the problem we're trying to solve.
Here's the wrinkle: Some of services queried by the data retrieval service want to implement user-level authentication, so that some users may access their data, but others cannot. For organizational reasons, our identity and authentication mechanism is likely to be Shibboleth.
So, here's my scenario: a user logs in to the frontend using Shibboleth. Now, can my frontend, and in turn, the data retrieval service, authenticate against against external services as the user? And if so, how does that work in practice (what authentication data gets passed from server to server)?
Yes it can - you service has to exist in the identity provider (how it is set up is up to you)
I've got two separate homemade applications that need to communicate among themselves. One is a frontend application (asp.net actually), the other is a backend interface to an accounting application. The backend interface was not created specifically for this frontend - it is a generic interface that many other applications use to integrate with our product.
For the convenience of users we wish to provide a Windows Authentication in our frontend application. That means however that we need to pass the credentials on to the backend application which has to check them.
We do not wish to set up our frontend as a "trusted" application to the backend which can authenticate itself as any user. If the frontend was to be hacked, it would then also compromise the backend system.
As I understand it, one way to do it with Windows Authentication is Kerberos Delegation. However this requires to be explicitly enabled for the user that is to be delegated, and the machine which does the delegation (the server with our frontend). By default these options are disabled in Active Directory, and I suspect that many sysadmins will have their reservations about turning them on for all their users.
Also, I'm not really sure that this is what Kerberos Delegation was meant for. I don't need our frontend to impersonate the user that is connecting. I just need to prove that this user has authenticated itself to me.
How would you do this?
I'm not clear what you can and can't do with your use case but I can answer the question what Kerberos Delegation was meant for.
First let's talk about what Kerberos does prior to delegation. It is important to understand this part well because it is subtle.
Kerberos authenticates the identity of BOTH ends of a communication between two end-points across a network, those end-points can be interactive users or services running on a computer.
This is strong authentication so it will not allow a man-in-middle attack in any form. If set up correctly an end point can guarantee they won't be compromised. To the level of the service name (if you are connecting to IIs on a machine it is different than connecting to SQL Server on the same machine). It makes heavy use of modern encryption techniques and requires the use of secure certificates. The details of the authentication protocol are complicated and not worth going into now, but it involves about 20 different distinct steps of confirmation between the two authenticating end points and authentication server (in windows the Domain Controller is the authentication server).
So what the heck is delegation?
Delegation is a Microsoft extension to the Kerberos standard which
allows a trusted source to continue the authentication to another
end-point.
This allows you to act as a "man in the middle" -- however many settings have to be explicitly setup, certificates installed, etc to allow this to work. It is far from simple. (EDIT: Here is another SO answer on the details - https://stackoverflow.com/a/954154/215752)
So, for example, you could have someone authenticate to a website and then have the .NET code connect to an SQL Server AS THE SAME USER to read data with that user's rights.
Now to answer your question, since I'm not sure what you want to do I present three choices:
1) You want to connect to the back end system as the SAME user as the one authenticating at the website.
In this case Kerberos delegation is perfect -- it does exactly what you want.
2) You want to connect to the back end system as a DIFFERENT user than the one authenticating at the website (eg a service account).
In this case you don't want delegation. Kerberos to the website and Kerberos (as a different user) to the back-end will work great.
3) You want to connect to the back end system as the SAME user some of the time and as a DIFFERENT user other times. (For example, you need to validate this is a legal user for the back end system, but want to perform trusted actions as a system account other times. This is (in my experience) the most common use case.)
In this case you use both. Delegation for the connections which need to validate the user identity and then revert to the service account identity for the times when you need system access to the back end. (A previous question of mine went into the details of how to revert to the system identity on the .NET platform see How to "un-impersonate" (un-delegate?) in Kerberos.)
Here is a post describing how Kerberos works and how to set it up.
ASP.NET passing along Windows Authentication credentials
Actually Kerberos delegation is designed exactly for this use case. But the challenge here is craft this on a legacy system and with AD's settings that you do not want to change.
One possible hack is to have the Front End just send the user and the time of authentication but the backend can query the Active Directory Event Logs to determine whether that user has authenticated to the Front end. This requires you to use WIndows Event Log API.and also play around with Event Log settings in AD to log the issue of service tickets. (MY recollection is that this is the default)
-