on 06-02-2014 9:57 AM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
User | Count |
---|---|
87 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.