Skip to Content

Using Single-Sign-On (SSO) with Widgets and SAP Systems

So you guys know by now that we’ve been internally experimenting with widgets for the past few months. Our first challenge was to enable widgets to access resources that use Secude Single Sign-On a login mechanism. This includes the SAP Enterprise Portal and other internal systems. A little about SSO (on Windows): SSO is quite simple once you understand how it works. When the user logs into the SSO client application, the user’s credentials are verified against a server and a temporary x.509 certificate is placed inside the user’s Certificate Store. You can see it if you look at the list of certificates in IE when SSO is running. In order to use SSO over HTTP, we simple include the certicate along with the web request. We wanted a solution that: 1- Did not prompt the user for any kind of password 2- Did not store or expose any of the user’s credentials (on the disk or in the registry) 3- Would work only when SSO was active Here’s what we ended up with: We wanted a quick and easy way to simply access the Windows Certificate store. .Net 2.0 has some built in functions to do that. We created a proxy class, which given a url request, will add the certificate to it, execute the request and return the results. Step 1 – Create the .Net Proxy We create a simple command line program which takes as it’s parameters, the url to be called and any form fields to be passed in. We use a standard .Net HttpWebRequest object. Here is the part that accesses the certificate store.  HttpWebRequest req = (WebRequest.Create(url) as HttpWebRequest);  X509Store store = new X509Store(StoreName.My);  try  {   store.Open(OpenFlags.ReadOnly);   foreach (X509Certificate cert in store.Certificates)   {    if (cert.Issuer == “CN=SSO_CA, O=SAP-AG, C=DE”)    {     req.ClientCertificates.Add(cert);     signedonce = true;    }   }  }  catch  {   Console.WriteLine(“–>ERROR:PSE ERROR<–“);   Environment.Exit(-1);  }  finally  {   store.Close();  } Step 2- We call the command line proxy from the widget using the runCommandInBg command. If anyone is interested, let me know. I can post the rest of the code. This solution meets all of the criteria we set above, but does require the use of a command line program as well as the .Net framework 2.0 which is still not common on most user’s machines. This will of course not work on Macs. Do any of you have a more elegant solution, using .Net or not ? Has anyone come across this or can contribute other authentication methods ?
You must be Logged on to comment or reply to a post.
  • Hi Frederic,

    can you please provide us all required information? I think I didn’t got you with the temporary X.509 Client Certificates. We have a Portal and use SSO via NTLM with IISProxy. But I don’t see a X.509 certificate. What I get is a SSO2 Logon Cookie. Do you mean that?


    • Gregor,

      Frederic  being an SAP employee, I strongly believe he is referring to SAP’s internal SSO solution (which is actually secude for mysap). It is a PKI-based solution (no temporary but permanent x.509 certificates) that comes with a GSS-API library for SAPGUI access via SNC (actually the sapcryptolib…). For people not on the SAP payroll, using this approachs means buying some 3rd party software.


      • Hi Dominik,

        that’s only partially true. Brian is describing the so-called “automated certificate enrollment” process: initially the user is not equipped with a X.509 client certificate, so no such certificate is send along with the https request. The system (acting as RA, Registration Authority) will then prompt for UID/PWD and verify that information. If the logon information is correct, a certificate request is triggered and send to the CA (certification authority), being signed by the RA (registration authority). The user will then receive the certificate response (from the CA) instantaneously. In parallel the server will create a mapping (X.509 client certificate => user account) for that user. Next time the user can logon using that X.509 client certificate.

        It is important to notice that the X.509 client certificate (and the corresponding private key) is stored in the keystore of the frontend PC. The server has no access to the private key. However, if no keystore roaming is provided (by the OS), the user will not be able to use that X.509 client certificate when using a different PC.

        Regards, Wolfgang

        • Sorry, it was not Brian but Frederic …
          And the described “automated certificate enrollment” was originally developed for the SAP Workplace 2.11 (predecessor of the SAP Enterprise Portal solution). It’s part of the “SAP Trust Center Services” (TCS, see:

          Cheers, Wolfgang

          • Wolfgang, thanks for clarifying.

            The solution described above is only meant to work with the “Secude Single Sign On” that we use in-house at SAP as well as some customer sites. If you are using Kerberos or NTLM this solution will not work for you. I will post on SSO2 Ticket Handling soon.

  • Hi Fred,
      What exactly are the capabilities of the widget’s javascript codebehind?
    Is it just like any other javascript running in IE context?


    • Hello Eran,

      The javascript used in widgets (in Dashboard and Yahoo at least) is not as “Sandboxed” as the JavaScript running in IE. Widget engines provide a JS API to access system functions and execute compiled code. Widgets in Dashboard have a plug-in model that allows you to supplement your JavaScript with compiled code that has the same access to system resources as any other program.

      From a security stand point, Widgets should be treated the same as regular applications.

  • We are working on a similar project and are interested in seeing the rest of the solution as well.   One question.  When you speak of temporary x.509 certificates, are you saying that the user retrieves their x.509 certificate each time they log in?  or is it a one time issue of the certificate that the client uses for each subsequent log in?   In our use case we are wanting to include session management through a web portal and pass a temporary x.509 cert to the client for use during that log in only.