SSO strategy

[Former Member]

Hi all

At my current client the windows logon are authenticated by the AD. When the user logs on either to SAP or to Portal the Kerberos protocol is used to authenticate the user and to achieve SSO.

The client wants to use SAP Logon tickets to support SSO for future SAP applications. But a Logon ticket is only created when the user logs on to the portal and stored in the browser as a cookie.

Therefore will the logon ticket still be created if the user logs in to windows and Kerberos authenticates the user logon to the portal, or will you need to manually log on to the portal to create the logon ticket?

If not logon tickets, what will be the best SSO strategy to use if the client wants the initial logon to be the OS?

Thank you

[Former Member]

What the best SSO strategy is for your company depends on many aspects - technical, financial, etc. - and you also have to look further ahead.

One SSO option for SAP is a certificate-based SSO based on SNC. This does not require SP Portal. You can still authenticate via Windows logon. SNC is supported for a wide variety of SAP technologies, and the standards-based certificates can also be leveraged for other tasks (e.g. digital signatures, ...). There are a number of companies providing SNC solutions. Not all of them may support Windows authentiation, though.

Disclosure: I represent a company - SECUDE International - www.secude.com - that provides an SNC solution with Windows authentication.

[tim_alsop]

Wian,

It looks like you are using the correct/best approach for SAP GUI and Portal, and when the user logs onto the Portal using Kerberos authentication (e.g. Integrated Windows Authentication) your ticket login module stack in J2EE engine will be creating an SSO2 logon ticket so that they only have to authenticate once to access portal pages, and don't need to authenticate again until browser is closed and re-opened to access portal again.

So, in answer to your specific question - yes, the logon ticket will be created when user logs onto Windows and then accesses the portal, and the logon ticket cookie will then be used for all subsequent page requests. If the user closes all copies of browser and opens browser to access portal later in the day they will be re-authenticated using their Kerberos credentials which were issued when they logged onto the Windows workstation where browser is located.

Unless I have misunderstand - it sounds like you have already chosen the best strategy and it is all working well for you. I am wondering why/if you have any doubts ? Maybe there is a specific functionality you are looking for which you are not getting with your current solution ?

Thanks,

Tim

[WolfgangJanzen]

The "SAP Logon Ticket" can be considered as "internal glue": it can be evaluated by all (SAP) backend systems (that have decided to trust the ticket issuer, which typically is the (SAP) Enterprise Portal). But, as you have described correctly, you first have to provide valid logon credentials (UID/PWD, X.509 client certificates, SPNEGO/Kerberos, ...) when you "enter" that (SAP) hemisphere.

In future releases the (proprietary) SAP Logon Ticket (as well as the SAP Assertion Ticket) might be substituted by standard-based security tokens (e.g. SAML) which would then ease the integration of third-party backend components - and would also allow to use a 3rd party token issuer. Of course, the existing (proprietary) tokens (such as the SAP Logon Ticket) will continue to be supported (they will <u>not</u> disappear) for legacy systems.

So much from my side.