Secude (securelogin) as SSO application for SAP

[Former Member]

Hi everyone,

We are currently evaluating the Secude product securelogin for an SSO implementation at a client.

I was wondering if any of you have come across or are currently implementing this product. I would appreciate it if you could let me know of any concerns/problems with using this product.

Thanks & regards

Sujeet

[tim_alsop]

What are you planning to use it for ? Is it for SAP GUI authentication to SAP app servers ? Do you have Active Directory ?

[tim_alsop]

Hi,

According to the datasheet PDF document available on secude.com the product works as follows :

The SECUDE securelogin server receives

authentication information from the Microsoft

Windows login and forwards it to the Active

Directory Server to request confirmation. If the

Microsoft Active Directory Server successfully

authenticates the user, a temporary certificate is

created for that user. This certificate is sent to

the client workstation and made available to both

the SAP GUI for Windows and the SAP GUI for

HTML, allowing certificate-based login to the SAP

R/3 Enterprise Platform, SAP Enterprise Portal,

and SAP Web Application Server without a

corporate PKI.

This means that the normal login to a domain which is performed by Microsoft Windows has to be changed so that the user is first logging into a new secude authentication server, which then communicates with MS AD. From a user perspective I am sure this is ok, but from an IT perspective it means that the Windows GINA has to be updated/replaced and additional servers need to be deployed on the network. This will clearly require additional costs and time/resources. If instead, you use an SNC solution based on the Kerberos protocol you can take advantage of the standard Windows login which is already being used, and use the Kerberos credentials already cached on the workstation to authenticate to you SAP server. This will not require any additional servers to be deployed/managed, or require changes to the standard Windows login code, so the costs are greatly reduced.

I hope this helps.

Thanks, Tim

[Former Member]

Hi Tim,

Thanks for your reply.

We were considering the Windows based option, along with Kerberos. However there are a number of custom applications which the client uses, and we need to cater for SSO to these apps as well.

One consideration was to allow SSO via the Portal, but most of the apps would require significant customisation for this to work. Therefore a third party product would just simplify the task.

Have you come across any other third party products that are simpler for a SSO implementation?

Regards

Sujeet

[tim_alsop]

Custom apps can also be implemented using the Kerberos protocol. The company I represent (CyberSafe) have products which address these needs, as well as providing products for SAP SNC security and SSO. There will be no additional infrastructure required because we use the existing MS AD servers for authentication of users, and key management. If you want to discuss our products I would like to suggest we discuss offline (you can get my email address from SDN business card) since it is not appropriate to discuss details such as this in the SDN forum.

[Former Member]

Sujeet,

I am the guy that did (almost all) implementations of SecureLogin at customers sites and I travelled all the world. There are numerous customers using this product to their fullest satisfaction...

Secude SecureLogin CAN use Windows credentials (for which it CAN be integrated in Windows) but not necessarily so. Secude and SAP defined the SNC interface and the Secude SNC library is also distributed by SAP as the SAP Crypto Library. It is not necessary to use non SAP software at the server side (saving you a lot of support headaches in the process) as SecureLogin can use the SAP Crypto Library.

SecureLogin generates standard X.509 certificates that can be used inside a browser to implement SSL with client authentication.

After the client receives a certificate from the SecureLogin server (which can a SAP Netweaver as well; the product is certified as "Powered by Netweaver") it can securely connect to SAP servers and all SSL enabled web servers at will and as long as you want to. This is not true of Kerberos where each connection MUST be via a Kerberos server before the actual connection can be set up.

Kerberos in Windows XP also uses weak encryption (only MD4 and DES) so it's not secure. This will be solved by "Longhorn" which is still not there.

Please feel free to contact me if you still have a question...

[tim_alsop]

> Secude SecureLogin CAN use Windows credentials (for

> which it CAN be integrated in Windows) but not

My definition of using windows credentials, is where the credentials issued by Active Directory during a normal domain logon to Windows occurs e.g. no changes are made to standard MS Windows workstation software, and no changes are made to domain controller functionality. So, Secude SecureLogin does not use Windows credentials because it is not using the Kerberos tickets which are obtained during this domain logon, and cached on the workstation in a credentials cache. Instead, it requires x.509 credentials to be issued separately to the credentials which are normally issued during Windows domain logon.

> as you want to. This is not true of Kerberos where

> each connection MUST be via a Kerberos server before

> the actual connection can be set up.

This is not correct. The Kerberos server is only contacted when user logs onto their workstation using their domain account, and when they first connect to a specific SAP instance (to get the service ticket). From that point on the credentials (e.g. Kerberos tickets) are cached on workstation and reused to avoid any unnecessary communication with the Kerberos server.

> Kerberos in Windows XP also uses weak encryption

> (only MD4 and DES) so it's not secure. This will be

> solved by "Longhorn" which is still not there.

This is NOT true. The default encryption type is RSA RC4 with HMAC-MD5 hash. Most software uses this encryption type to avoid changing Active Directory to use DES. If you think that DES is the default, then this might be because of a product which is not using latest Kerberos standards. There is no need to upgrade to Longhorn to support RC4-HMAC-MD5.

It is true that Longhorn is supposed to have support for 256bit AES, but this is not yet confirmed. Most companies are happy to use RSA RC4 with 128-bit and HMAC-MD5 hash.

> Please feel free to contact me if you still have a

> question...

I hope the above helps.

Thanks,

Tim

[Former Member]

Tim:

I hope we can avoid a pissing contest....

1. Secude SecureLogin uses Windows credentials to generate a X.509 certificate. If you're using the GINA integrated client, the process is completely transparent. A normal user will never even notice this.

2. I said MD4, but I meant RC4. Thank you for the correction. RC4 is considered insecure (you can for example check http://en.wikipedia.org/wiki/RC4 for that).

And thank you for the confirmation of my other points...

Cheers,

Sietze

[tim_alsop]

> I hope we can avoid a pissing contest....

yes, I do also. I am trying to make this an informative chat about differences between various solutions. Sorry if this is not the way it is being read.

> 1. Secude SecureLogin uses Windows credentials to

> generate a X.509 certificate. If you're using the

> GINA integrated client, the process is completely

> transparent. A normal user will never even notice

> this.

So, to help me understand - does secude client software use a Kerberos secured session to communicate with a server (e.g. via SSPI or GSS-API) and then the server accepts the context to determine the ID of user logged on, and issue a short term cert for this user ? If not, then I cannot see how the client software can use the Windows credentials to generate a cert for the logged on user.

> 2. I said MD4, but I meant RC4. Thank you for the

> correction. RC4 is considered insecure (you can for

> example check http://en.wikipedia.org/wiki/RC4 for

> that).

Actually, RC4 with HMAC-MD5 is not insecure when used with Kerberos protocol so the URL you mentioned is not applicable. I can send you more info on this if you need to better understand why... It is simply the standard cipher which MS AD uses, and is considered by many to be secure and acceptable for use in a Windows/UNIX environment for authentication, and strong session security.

> And thank you for the confirmation of my other

> points...

No problem. If you want to continue discussing various product features etc, I think we should do that offline from SDN. you can get my email address from my business card.

>

> Cheers,

> Sietze

[Former Member]

Tim,

Yeah. For the finer details it may be better to continue this offline. I can only hope the original poster got his question answered. If not, please say so. After all, he wanted some information about Secude SecureLogin, not about Kerberos.

For me, the term "credentials" has a wider definition. SecureLogin actually uses the Windows username/password, which it gets from registering a network provider. This is a clearly defined interface that doesn't break things (unlike for example a smart card provider, which we also have). It is feasible to use Kerberos as well (the architecture allows for it), but no customer wanted this until now. It is therefore necessary to encrypt the communication between SecureLogin Client and Server with SSL.

MD5 is broken as well. As you know the chain is as strong as its weakest link and we now identified two weak links. MIT Kerberos supports 3DES and AES, I wonder why MS doesn't do this until "Longhorn" which is a long time away.

[tim_alsop]

Sietze,

I find that when I want to understand a product, as the original poster wanted - it is best to understand how it compares to something you are already familiar with. I am more familiar with Kerberos, and Active Directory authentication than I am with Secude software. I am sure the original poster is watching this discussion and hopefully learning from it ...

Yes, I am familiar with the network provider. This has been available in Windwos since Windows 95/98 days, and used widely by vendors such as Novell, and other companies that want to use the Windows password for logon to another network service. If you need to know the ID of the user logged on at the workstation it is more secure if the password is not transmitted and then checked again on a server. This is why SSPI is available in Windows. e.g. Windows does not pass the password of a logged on user to a Windows file server to allow the server to know the ID of user logged on at workstation. When using SSPI and GSS-API (if on UNIX) there is no need to transmit any passwords, not even in encrypted form, which I hope you will understand is more secure than any form of password transmission.

MIT Kerberos actually supports RC4 as well as DES and AES. Anyway, I would not recommend anybody uses MIT Kerberos with SAP as this is not supported or SAP certified. The use of AES in Kerberos was not standardised in time for MS to add this to Windows Server 2003, so they are adding it to Longhorn, which is their next server release.

We could probably continue this conversation for a long time, but I think we have already covered the main points of comparison and I hope that the info is enough to help the original poster, and not confuse them.

Another consideration, when looking at the Secude software is the need for additional servers. e.g. If an Active Directory infrastructure is already in place, then often there are many servers already deployed on the network, and managed. Some customers I have worked with have >200 servers in their worldwide network. If an additional authentication server is required, then this increases complexity, and costs. This is why I suggested to the poster that Kerberos might be worth looking at - he will not need to deploy another authentication infrastructure to sit along side his existing Active Directory servers.

Thanks,

Tim

[Former Member]

The Secude software does not mandate the use of additional servers (like a Kerberos Server). This is only necessary if you're using SecureLogin. And the SecureLogin server is only necessary once during a Windows session and NOT with each connection with a SAP server as with Kerberos.

[WolfgangJanzen]

"[...] pissing contest [...]" - please calm down, guys.

Such (verbal) fights do not help anyone.

[Former Member]

Thanks Sietze & Tim...

You have both provided some valuable input, however we are evaluating a number of vendors so we are still some way from making a decision.

I see that both of you have email addresses on your business cards, and if it is okay with you then I will contact you individually if I require some additional.

Thanks & regards

Sujeet

[tim_alsop]

Sujeet,

Yes, this is ok with me.

I look forward to helping you more.

If this SDN message is finished with, then I suggest you issue points so it can be marked as completed.

Take care,

Tim

[former_member187674]

Hello Sietze,

My customer is thinking of SAP GUI SSO. Can you please let me know how can I contact you in this regards?

Regards,

Muniraju

[Christian_Cohrs]

Hi Muniraju,

the post from Sietze is rather old and in the meantime there is a large number of consultants out there that implemented SAP Single Sign-On, both SAP Consulting and 3rd party consulting.

I'd suggest your customer gets a demo license for SAP Single Sign-On from his SAP account executive and just tries it out. SAP GUI SSO is really simple to implement. You might not even need a consultant.

Best regards,

Christian