Failover configuration on SLS - how to set the Profile ID (GUID)?

[Former Member]

Hi Experts,

with Secure Login Server you have two choices how to deploy the client policy. One is to use „dynamic“ policy download by only distributing the PolicyURL to the Secure Login Client, where the client can then download the latest Secure Login Client profiles (ProfileDownloadPolicy). An other way is to use the "static" policy contained in the ProfileGroup registry file you can download from the SLS.

To achieve high availability/failover we recommend our customers to use at least two Secure Login Severs. Given the fact now I have two Secure Login Servers, in the Client Authentication Profile -> Secure Login Client Settings I have to add two enrollURLs. I would assume on each SLS there is an different GUID or Policy ID generated, right? This is the failover configuration for the Secure Login Client. If the first Enroll URL cannot be established, the Secure Login Client tries the next Enroll URL, defined.

Example: One enrollURL0 (primary SLS) and enrollURL1 (second SLS).

While adding an enrollURL i am only able to set Protocol, Hostname, Port and Version of the Secure Login Client. Where i can define the ID of the Profile?

One first need to setup the second SLS, get the Profile ID and add this to the policy configuration on the primary server, but there is no way to do so.

Example in the ProfileGroup_<ProfileGroupName>.reg (or after downloading the Policy from the primary server - will be contained):

"enrollURL0"="https://<server1>:<port>/SecureLoginServer/slc2/doLogin?profile=a584209c-5de8-4bf7-85da-58d1cf3b1072"
"enrollURL1"="https://<server2>:<port>/SecureLoginServer/slc2/doLogin?profile=a584209c-5de8-4bf7-85da-58d1cf3b1072"

Now I have the change the Profile ID (GUID) of the enrollURL1 manually to match the correct Profile ID of the second Secure Login Server.

My question is, have I missed something or is a failover configuration only possible by manually modifing the registry file downloaded from the SLS and replacing the GUID with the right value?

Please let me know.

Regards,

Carsten

[former_member251763 · Accepted solution]

Hi Carsten,

we solved it by using a load balancer (round robin, client ip persistance) and two Secure Login Server.

My assumption: to provide a high available single sign service, the sso servers have to be independent. Otherwise a database downtime (e.g. maintenance during working hours) would be impossible. The availability should be as high as possible (near 100%).

Possible solution 1:

The servers will use (of course) different profile group IDs, so the PolicyURL (client windows registry) has to be a generic one:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\SAP\SecureLogin\System]

"PolicyURL"="https://<loadbalancer>/globalPolicyURL"

BTW: this is a good solution to switch the profile group (online) without a new registry setting rollout (client site).

...and the ICM (both Secure Login Servers) needs a rewrite rule (example):

[default profile]

icm/HTTP/mod_0 = PREFIX=/,FILE=$(DIR_GLOBAL)/security/data/icm_mod_rules.txt

[icm_mod_rules.txt]

if "%{PATH_TRANSLATED}" regimatch "/globalPolicyURL"
RegRewriteUrl "^/globalPolicyURL(.*)" "/SecureLoginServer/slc/getProfiles?grouppolicy=<individual generated profile group ID of sso server>" [code=temp,qsreplace]

The servers will use (of course) different profile IDs. So a rewrite ruleset (example) is needed again:

[icm_mod_rules of server one]

if "%{SERVER_ADDR} = <IP of server one> [AND]
if "%{PATH_TRANSLATED}" regimatch "/SecureLoginServer/slc2/" [AND]
if "%{QUERY_STRING}" regimatch "profile=<individual profile id of server two>"
RegRewriteUrl "^/SecureLoginServer/slc2/(.*)" "/SecureLoginServer/slc2/$1?profile=<individual profile id of server one>" [code=temp,qsreplace]

[icm_mod_rules of server two]

if "%{SERVER_ADDR} = <IP of server two> [AND]
if "%{PATH_TRANSLATED}" regimatch "/SecureLoginServer/slc2/" [AND]
if "%{QUERY_STRING}" regimatch "profile=<individual profile id of server one>"
RegRewriteUrl "^/SecureLoginServer/slc2/(.*)" "/SecureLoginServer/slc2/$1?profile=<individual profile id of server two>" [code=temp,qsreplace]

Attention: the rewriting rule for the url /SecureLoginServer/slc2/ is needed for each profile ID of the (shared) profile group. Only a ICM restart is needed to enable/share a new profile or profile group.

Possible solution 2:

Use a "template Single Sign On System", that will be used as a central configuration template for all sso servers. The (productive) sso servers will be created via a system copy of this template system. Then all IDs will be the same.

Both solutions are not very handsome, but stable.

And i agree:

Feature request for SAP to enable editing the GUID manually within the SLAC

Best regards and greetings to the secude team

Kai

[Former Member · Accepted solution]

Hi Kai,

thanks for sharing this, for sure also valid approach to use NLB.

Kind regards,

Carsten

[Nik3 · Accepted solution]

Hi Carsten,

I am on SLS SP5 PL2 and you still cannot edit the profile ID manually within SLAC.

Do you know for which SP the feature request to enable editing the profile ID manually within SLAC is planned?

Thanks and BR

Nik

[former_member200373 · Accepted solution]

Hello,

with SLS 2.0 SP06, you can edit the "Profile ID" which is part of the URL. But it´s recommended to do failover and load balancing on backend side, not in SLC.

See my blog about this topic, also mentioning the new profile ID edit feature:

-- Stephan

[Nik3 · Accepted solution]

Hi Stephan,

thanks for your quick response. Could you quickly explain me what you mean with "it is recommended to do failover (...) on backend side, not in SLC"? So what is the recommended way?

BR

Nik

[kuhnen · Accepted solution]

Hi Niklas,

You should have a Netweaver AS load balacing solution. The  Netweaver AS should take care of the failover and not the SLC.

Regards,

Marcus

[Nik3 · Accepted solution]

Hi Marcus, just for my understanding. I am looking for a solution for failover scenarios. Could you please describe in more detail what you mean with "NetWeaver AS load balancing solution". Would it be e.g. by using SAP WebDispatcher or do you mean an OS (operating system) cluster? Thanks for clarifying. Nik

[Former Member · Accepted solution]

Hi Stephan,

glad to hear it is implemented now. I agree, having FO/NLB on the backend seems to make more sense, however this requires more resources and effort for those infrastructure components... THX

[kuhnen · Accepted solution]

Hi Niklas,

the details of how a solution would look like is out of my scope. I think you should look for someone who has more experience on settingup this kind of backend fail over solution.

Regards,

Marcus

[asif_rahmetulla · Accepted solution]

Hello Kai,

Thank you for putting together detail solution!

We are trying to implement the failover for SLS as well with SAP Web dispatcher in the front as the load balancer with SAP SSO 3.0.

Question - Your proposed solution was from 2015. Did SAP introduced the feature to enable editing of the GUID manually with the SLAC so that both the SLS nodes have the same GUID?

Regards,

Asif

[Former Member]

Hello Carsten,

normally SAP recommends to use a SAP Webdispatcher and 2 or more Netweaver behind, which are connected to the same DB. In this case you will configure one EnrollURL on the clients with one profile GUID and the Dispatcher will do the rest.

The profile configuration will be the same on all Secure Login Servers based on the same DB.

This is a more "big" solution but also has the benefits of load balancing and not only failover.

best regards

Alexander Gimbel

[kuhnen]

Hi Carsten,

you didn't miss anything. You are right, one cannot configure the GUID on the SLS. You have to manually modify in the registry file.

Regards,

Marcus

[Former Member]

Thanks Marcus, thats good to know. What Alexander said is fully right, but not all customers want to have such a "big" setup only for SLS failover and load balancing guess makes sense for very large customers with lots of Enrollment Requests to the SLS engine.

Feature request for SAP to enable editing the GUID manually within the SLAC

Thanks!

Regards,

Carsten