Single Sign-On with arcplan Enterprise
Users expect to access portal content in their browser with with just one single login dialog. Different Single Sign-On (SSO) techniques have been developed to solve this problem and the common ones are supported by arcplan Enterprise.
All SSO techniques require, that the arcplan server somehow authenticates the client user against the database without the possibility of outside interference.
The client needs some kind of ticket, which enables the server to securely identify the users requests. The ticket can either be the windows logon ticket of the current user or it may be created by a separate instance like a web portal which uses the credentials entered when opening the portal and setting a cookie in the browser.
We can distinguish between four main arcplan SSO scenarios:
- The internal solution
The arcplan Server authenticates the user by a single username and password. All successive database access is internally mapped to the correct user credentials by the application
- The integrated solution
The arcplan Server receives a logon ticket from the outside (e.g. a web portal, or the windows operating system) which can be used to access the database directly.
- The generic solution
The arcplan server receives a ticket from the outside (e.g. a web portal), which can be securely mapped to a single user account by querying a user database. This account is then used to make successive database queries.
- SSO using External tools
An external software (like SiteMinder) is used to authenticate the user.
1. The internal solution
The internal solution uses a username and password entered once during the lifetime of the arcplan session.
This kind of Single Sign-On is only valid inside of arcplan. The user has to enter his credentials every time he navigates to an arcplan application, and it is therefore not considered as state of the art.
A workaround is to authenticate the user against a database on the arcplan server machine (e.g. using his Windows account) and map this account to generic user accounts valid on all other databases. Oracle's proxy user concept is just one common example of such a user mapping technique.
2. The integrated solution
Windows integrated authentication
Windows logon tickets are supported for many databases including SAP BW, IBM CognosTM1, MS SQL Server/Analysis Services.
But usually Kerberos is required to be enabled at the customers site. Kerberos is quite difficult to install, please refer to Microsoft resources.
Out of the box authentication for the SAP Netweaver portal
Because a SAP database can establish a trust relationship with the SAP Netweaver portal, a SAP portal logon ticket can be used directly instead of username and password. The browser just has to send the ticket back to the webserver.
The arcplan CGI will then read this SSO ticket and pass it to the session running on the arcplan server. The session will pass it automatically to the database if the logon parameters of the connection file are appropriately set. No other adjustment has to be made to the arcplan application or Netweaver portal.
Single SignOn in the SAP Netweaver portal
3. The generic solution
Using a separate database is a solution that will work on any portal. After the portal has confirmed the users identity it can send its own logon ticket to the browser and to the arcplan server create a new unique token using a small portal component, save it into al user database and send it back to the browser.
The arcplan application will receive the ticket/token through the browser and confirm its integrity. (with the user database or the Portal itself using a web service request). It will then log the user into the necessary databases using the appropriate generic user account.
Generic Single SignOn in a Web Portal using a user database
The disadvantage of this solution is the requirement for an additional portal (or web server) component. Since this component, which may be a servlet, a small asp .NET application or a Webservice, has to access a database it has to be customized for the portal and cannot be provided by arcplan Enterprise out of the box.
4. SSO using External tools
It is possible to exchange parameters with external tools like SiteMinder, but needs to be evaluated on a case by case basis. Please contact your support center for further assistance.
 A browser contact is usually stateless. This means that the server side can not uniquely identify the browser. To enable a trust relationship the browser has to send its credentials in form of a logon ticket inside of the request. The server side will then check for each request if the ticket is valid and provide the requested content.
The logon ticket may either be the users logon ticket from the active directory, or a ticket created for the browser session using basic authentication.
The arcplan server also needs such a ticket internally to ensure that a clients request for data will be handled by the right arcplan server session.
 The simpler NTLM ticket is only trusted between the end users computer and the arcplan server. If the database is located on a third machine it will not accept the ticket and SSO will fail. This is a major difference to other web applications, where the browser client will directly contact the database using NTLM.
 SAP Netweaver provides the ticket as a domain wide cookie. Due to increased security restrictions of Netweaver 2004 the arcplan Client will no longer send the SAP logon ticket automatically to the web server because it is a so called http-only cookie. This special kind of cookie will not be send when a web server request is made by the Sun java virtual machine.
A special ASP start page can be used to transform the original ticket into a "normal" session cookie.
It is also possible to use a "normal" html page if the SystemCookiesDataProtection option in the Netweaver HTTP provider service is set to false. (See SAP Note 943336)