How to implement SSO to non-SAP systems using SAP logon ticket?

[Former Member]

Hello,

We would like to implement Single Sign On between our SAP Netweaver system and a Siebel which is a non-SAP system using SAP logon tickets.

Can anyone please give me some leads on this, in particular:

1. Is there a JAVA API or an SAP plug-in that can be implemented on the Siebel machine to extract the SAP logon ticket?

2. As the other machine might seat on a complete different domain, is it possible to implement SAP logon ticket without using cookies (perhaps through the HTTP header?

3. In case you think using SAP logon tickets is not the best solution here I would be happy to hear any other suggestions you might have.

Roy

[tim_alsop]

I would like to better understand what you are trying to acheive ? For example, do you want users to logon to the SAP portal, and then click on a link which launches Siebel in their browser without them having to re-authenticate ? If you can confirm this I will summarise the options available to you.

I think you will find that using SSO2 logon tickets will be very difficult (or impossible) since your Siebel server might be on a different domain. The SSO2 logon ticket issued by a SAP system is stored in browser as a cookie, and the browser would not send the cookie to the Siebel system if it is on a different domain.

Thanks,

Tim

[Former Member]

Hi Tim,

Allow me to elaborate then:

Your description was correct, I would like that once the user has logged into the SAP portal he will then be able to access the Siebel system with re-authenticating himself, either through a link which will open new browser window or through a portal iView (preferable).

Now, I am aware of the SSO2 limitations you have mentioned, I've raised them aas well and was wondering whether there is a different way to implement SSO2 so that it will support different domains.

In case not and anyway, I would be happy to hear what you suggest in this case.

Thank you in advance,

Roy

[tim_alsop]

Roy,

From my experience the best way to solve this kind of problem is to use the same source of authentication for both the SAP Portal and for the Siebel applications. For example, the user would authenticate themselves using Active Directory account when they logon to their Windows workstation, and their credentials issued by MS AD at that time could be used to authenticate them to the Portal (using the Negotiate protocol), and then when they logon to Siebel they could also be authenticated using MS AD credentials.

I am familiar with both SAP Portal and Siebel and I know they can both support this form of authentication, so you can implement the SSO you want using this approach.

Please let me know your thoughts on this suggestion ?

Thanks,

Tim

[Former Member]

Hi Tim,

I was thinking in this direction as well.

The portal is already connected to our Active Directory and users are authenticating themselves to the portal using their NT logon, so at least one side is done.

Although I'm very much familiar with the portal side, I am not familiar with the Siebel, it's the first time I need to make such an integration. Assuming the users on the Siebel are on a different domain but using the same LDAP server as us in order to authenticate to their system, can you please elaborate on how the SSO will be implemented in such a case.

Thanks,

Roy

[tim_alsop]

Roy,

ok, sounds like you already have SAP portal sorted, and just need to implement the same with Siebel applications. To implement the same method of authentication for Siebel applications you need to ask Siebel for help. I suggest you first contact Siebel and if they are not helpful, or don't understand what you need, please make contact with me again outside of SDN, so that I can help you with Siebel SSO.

Thanks,

Tim

[Former Member]

Hi Tim,

OK, so is it true to say that the prerequisite for this to work is that the Siebel system will authenticate it's users against the same LDAP?

Assuming it is and they are doing it already, can you please refer me to a documentation on this SSO implementation?

Thanks,

Roy

[tim_alsop]

Roy,

It is not appropriate, and not possible for me to discuss the implementation of Siebel SSO on SDN. As I mentioned in my last post, please contact me outside of SDN if you need more help with Siebel.

Thanks,

Tim

[Former Member]

Thanks Tim will do, just sent you an email.

[former_member698570]

Hi Roy,

you do not have to use the same authentication database. You can also use the SAP Logon Ticket issued by the SAP System (MYSAPSSO2 Cookie) and validate the ticket in a third Party System.

This means that both systems are in a trust relationship which means that you actually trust the SAP System and just authenticate a user within the 3rd party system by trusting the information in the ticket.

SAP offers a library called SSOEXT to validate logon tickets. You will also need SAPSECULIB. You can download the software from the SAP Marketplace. It is available for different OS. I've used it in JAVA a couple of times.

This approach uses native OS libaries (e.g. dlls in Windows Systems). There is also a different approach using a SAP Library (JAR) that works without native libraries.

There is a limitation of this approach:

Since you are working with cookies the 3rd party system should be in the same domain as your sap system so that the cookie reaches the 3rd party backend. You can than fetch the cookie from the HTTP Request to the 3rd party backend and validate it using SSOEXT.

If you need further information about this let me know. I can also provide some Code if necessary!

This might be useful:

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/47d0cd90-0201-0010-4c86-f81b1c81...

Cheers

[Former Member]

Hi Marcel,

Thank you for the detailed response.

The limitation you have mentioned with extracting the SAP logon ticket is something we aware of and perhaps will be the reason why we can't implement it this way.

I still need to check on the Siebel side whether it's in our domain or not, if it is we will definitely use this approach, my only concern is how to move forward in case it's not.

Just a question tho - You say that in case of using this approach I do not have to use the same authentication database. I understand how authentication will take place using this trust (the other side simply accepts the ticket and trust it) but how can the other system use this ticket in order to preform authorizations?

Roy

[former_member698570]

Hi Roy,

the other system will surely need to be aware of the users. Let's say the ticket contains information about user test123 then the 3rd party system has to know the user as well. I guess the system has its own user store since you also have to be able to authenticate directly to the system right? The best case would be that the usernames in the 3rd party user store are identical to the users in the SAP Userstore. I think that's why Tim propsed to use the same User store (e.g. same LDAP). But this only works if both systems are located in the same company or system landscape.

If the usernames are not identical they have to be mapped to the ones in the backend system using a mapping table.

In any case you have to modify the authentication logic in your 3rd party system (e.g. use JAAS and write your own loginmodule that actually validates the logon ticket and optionally maps the user to any other user.

You could also add a component (proxy etc.) in between both systems that adds any other information that can be used by the 3rd party system in order to authenticate the user such as Header Variable. The SAP System offers a JAAS HeaderVariableLoginModule. You could implement such a module in your 3rd party system in order to authenticate the user on the basis of a request header such as REMOTE_USER: <username>

For security reasons you have to make sure that this header is only recognized when added by a trusted system (e.g. check the source IP)

Hope this helps

Let me know if you need any more ideas...

Cheers

[Former Member]

Hi Marcel,

Thanks again for your detailed and clear response.

OK, things are getting clearer now: It looks like the other side will be sitting outside of our domain, hence the SAP logon ticket is not an option. We will not be using a common user store but will make sure that usernames are identical in both systems. Now, apparently the other side supports SAML which means that we will need to extract the username from the UME and send it using SAML, meaning we will be the identity providers.

Does anyone have such a code example in Java for the identity provider, not the UME part which I know but for the SAML over SOAP?

I know that there are many sample codes out there (google) but I'd rather see one that some of you have already used.

Roy

Edited by: Roy Cohen on Jun 26, 2008 5:10 PM

[former_member698570]

Hi,

I'm currently using SAML as well. Unfortunately the SAP J2EE cannot work as authority (identity provider) but what you can do is using an open implementation of SAML such as opensso which is an open version of SUNs Java System access manager.

There are a couple of other projects such as opensaml, apache's wss4j or shibboleth that might be interesting in this context.

I just installed opensso and got it working with SAP J2EE 7.0 using SAPs JAAS SAMLLoginModule to authenticate users within SAP J2EE.

In this scenario opensso serves as identity provider just as you need! There are a couple of Policy agents available on SUNs Download site you can use with Apache, Tomcat, JBOSS, WebSphere, Bea Web Logic etc. in order to authenticate! Otherwise you just directly authenticate against opensso. When installing opensso you can configure the type of user store you want to use! By default it uses LDAP but you can also use different types of user store using JDBC or other mechanisms. Since you have a Directory Service you could easily connect it to your existing directory.

There is also a way to map user ids directly in opensso by adding a uid mapping class. I created some documentation with lots of screenshots about using opensso with SAP J2EE. You can easily use opensso with any other system that supports SAML. In the case of SAP the usage is currently limited to SAML versions 1.0 and 1.1. Version 2.0 is not yet supported but should be in one of the following versions.

Here are some links you might want to check:

OpenSAML: https://spaces.internet2.edu/display/OpenSAML/Home

wss4j: http://ws.apache.org/wss4j/

shibboleth: http://shibboleth.internet2.edu/

opensso: https://opensso.dev.java.net/

On SDN you will find a documentation on how to connect SUN Java System Access Manager to SAP J2EE (see https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/906d9fc6-31b9-2910-1385-90edad7d.... As I said opensso is based on the SUN Access Manager code and looks quite the same. So you can adapt this documentation in order to configure opensso or you can just ask me for the documentation.

Hope this is helpful...

Let me know if you need further assistance on this topic

Cheers

[Former Member]

Wow, thank you Marcel, will do some reading and get back to you on that!

(meanwhile points for your hard work are assigned of course)