Hi Troy,
To quickly cover the SMS vs DSC thing: SMS was the previous incarnation of DSC. SMS used an external service (WebSphere "Extreme Scale") to provide a distributed cache. It was a complex component which required careful deployment planning and tuning to get best results and so it was definitely the case that you wouldn't want to deploy it if not needed.
The Distributed Session Cache is "lighter" than SMS with the advantage that the service is built into the Virtual Appliance. However, if enabled, it is still a critical component of the Reverse Proxy layer and if it's not working, or not available, then your ISAM system will be unavailable to users. So, it's still not sensible (from a risk/benefit point of view) to deploy it unless you need the functionality it provides.
It's worth noting that although you can have up to 4 DSC nodes in your environment, only 1 is handling client requests at any time. This means that scaling is vertical. In a very large environment you might struggle to scale each individual appliance hosting DSC to be big enough. I'm afraid I don't have the performance numbers to hand.
To answer the specific question about having Reverse Proxies in different places accessing DSC, this shouldn't be a technical problem. The issues you might have would be around connectivity and latency between the Reverse Proxies and DSC. To repeat, if a Reverse Proxy can't reach the current master DSC, it won't work. The more complex the connectivity requirements, the higher the risk of that aspect.
Your right that you wouldn't need DSC for API traffic. In fact, since DSC requires the use of a session cookie, you may want to actively avoid it for that purpose. Latest ISAM versions have option to automatically NOT use DSC for traffic that doesn't use session cookie.
I hope this helps with your analysis of the situation. I'm sure Scott will come back if I've misrepresented anything. Scott is "the man" when it comes to DSC so I defer to him in all cases.
Feel free to ask additional questions if you need to and we'll try to give you clarity.
Cheers... Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Wed June 03, 2020 12:00 PM
From: Troy Burkle
Subject: Stop Using DSC?
Yea I think there is a misunderstanding which is what I am suspecting and want to get cleared up.
I know Jon as I have been to a couple master classes myself. I did not attend last years session.
------------------------------
Troy Burkle
Original Message:
Sent: Wed June 03, 2020 11:40 AM
From: Franz Wolfhagen
Subject: Stop Using DSC?
I think that there may be a misunderstanding - I have never heard rumors not using DSC - so it may just be a misunderstanding mixing it up with the old SMS session management ?
Maybe Jon Harry can clear this up as I belive he was running the sessions.
------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
Original Message:
Sent: Wed June 03, 2020 10:55 AM
From: Troy Burkle
Subject: Stop Using DSC?
Thanks for the feedback Scott.
Do you know of specific reasons we should not use it? For instance, I would think the DSC would not be required for webseals dedicated for API services (OIDC/oAuth).
Is there a reason that virtual appliances or cloud based virtual appliances should not use the DSC? We have a combination of physical appliances on-prem, virtual appliances on-prem and virtual appliances in cloud (Amazon). With our cluster configuration, the DSC is hosted on-prem physical appliances. Is there any reason the virtual appliances on-prem and in the cloud should not use DSC that is hosted on-prem in our data center? I think this is what we are confused about the most because we have heard this through second and third hand communication. Right now there is a debate that if the DSC is required for a new webseal, that webseal should be created on the on-prem physical appliances. I think the person who told us not to use the DSC (who is no longer with the team) may have provided some incorrect information. I would not think it would matter what type of appliance (physical/virtual) is using the DSC.
Troy
------------------------------
Troy Burkle
Original Message:
Sent: Wed June 03, 2020 01:53 AM
From: Scott Exton
Subject: Stop Using DSC?
Troy,
I always tell customers that they should only use the DSC if they actually need the DSC. The DSC provides some nice capabilities (e.g. single log out and limiting concurrent user session), but it does come at a cost. The DSC will impact performance, introduces a new service into the environment, and has additional requirements around HA. If you don't need the single log out capabilities, or the ability to restrict the number of concurrent user sessions, you shouldn't use the DSC. If you want these capabilities you just need to understand the costs involved.
Does this make sense?
Thanks.
Scott A. ExtonSenior Software Engineer
Chief Programmer - IBM Security Access ManagerIBM Master Inventor
|
Phone: 61-7-5552-4008
E-mail: scotte@au1.ibm.com | 1 Corporate Court
Bundall, QLD 4217
Australia |
Original Message:
Sent: 6/2/2020 5:00:00 PM
From: Troy Burkle
Subject: Stop Using DSC?
A former colleague went to the IBM ISAM Master class last summer. One of the take aways he walked out with was that he was told that IBM no longer recommends using the Distributed Session Cache.
Is this true? If so, what is the theory?
Thanks,
Troy
------------------------------
Troy
------------------------------