CUA, SSO and Portal

[Former Member]

Hi Guys,

I'm a security guy, with CUA, Portal and SSO - but when it comes to installation of CUA and SSO with Portal, I have some gaps in my knowledge, so I could use a little help. Thanks in advance.

My client is implementing a non SAP SSO solution. As I've seen it before, it would be best to have that solution authenticate to the EP, and have EP issue tickets to the various SAP systems, and set up the SSO in that fashion. Would I be correct in my line of thought and do you have any more information on this?

Second, in my experience, CUA and SSO are quite separate, and so you don't need to implement one prior to the other. Would I be correct on this line of thought as well?

Third, on the Portal, is there a note number or a document from SAP that illustrates how to go about integrating Portal into CUA? I know that the portal roles are Java based and assigned via the UME, whereas CUA would have regular SAP roles.

Thanks,

Santosh Krishnan

[Former Member]

There are 2 special cases for using CUA with SSO for portals, but generally for a new implementation I would look into an IdM.

This is not limited to the ABAP stack and "workarounds" for the Java stacks and non-SAP worlds.

You should first read the security guides and latest informations yourself (use the search for the current infos) and then I recommend asking more specific questions when you get stuck or want to discuss an opinion.

Cheers,

Julius

[Former Member]

Hi Julius,

I have the security guides for Portal, as well as for PI, BPC and a variety of other products, which I shall be reviewing, in addition to the CUA cook book. Upon cursory review of those documents, I didn't see any topic that specifically targeted the integration of Portal with CUA, hence my question.

Further to your point on IdM, that has been my suggestion to my client as well, but they have already committed to a non SAP product, and it's outside my scope of influence.

Again, thanks for your response, and if you do have any material that you feel would be "recommended reading", please do give me the name/link to the documents.

Regards,

Santosh Krishnan

[Former Member]

The 2 obvious options are an LDAP sync and a UME pointing to an ABAP logical system representing the portal for the user store.

The latter option is not very scalable though in combination with CUA.

Good luck,

Julius

[Former Member]

Julius,

I've been told about the latter option by another consultant, and I think in this case, it might be quite a reasonable one.

Is there a document on service marketplace that discusses this?

Thanks,

Santosh

[tim_alsop]

Santosh,

It seems to me that you don't need to worry about CUA, since CUA is just what it says - central user administration. If you are just looking for a way to link the non SAP SSO to SAP Portal, then CUA is not involved in this authentication. Obviously, CUA might be used to create users and manage users in the user store that is used by portal, as well as other systems, but this is separate to the actual user authentication which occurs when a user logs onto portal.

Thanks,

Tim

[tim_alsop]

Santosh,

I am not 100% clear what you are asking about ? I can see that your client has a non SAP SSO solution in place. Are you just looking at a way to authenticate users who have authenticated out side of SAP and using this non SAP SSO solution to be able to logon to portal without having to re-authenticate ? If so, we need to know what this non SAP SSO product is and how it works, and what protocols/standards it supports. For example, does it support SAML ?

Thanks,

Tim

[Former Member]

Hi Tim,

Thanks for the good points. I have a meeting in 30 mins where I shall ask these questions. Basically, though, it's the Oracle IdM product that does SSO, and some other company is implementing it. That other company, from a few conversations I've had, don't have a clue on how to integrate it into an SAP environment. What's worse, my client is under the impression that installation, configuration and setup of SSO, and to some extent CUA, is a security task, rather than a BASIS task.

Regards,

Santosh Krishnan

[Former Member]

Dear folks,

Thanks for your information thus far. It has been noted from my meeting today, that the Oracle Identity Management solution that is being implemented here will do a rather unconventional screen grab method of password management - no tickets, tokens or what not. The implementation team (wherever they currently are) are customizing it to recognize specific screens and react accordingly.

The whole CUA connection comes up because, according to the [Oracle Identity Management SAP Guide|http://www.oracle.com/technology/products/id_mgmt/oxp/pdf/oimconnectordatasheet-saperp.pdf], it will tie into CUA in order to create, delete and manage users.

Again, thanks. I'm sure my problems have only just begun.

Santosh

[tim_alsop]

Santosh,

It looks like youa re going to have some fun !

An identity management tool is best used to manager users and application access (e.g. roles/permissions). It is true that many idm products allow a password for a user to be set in the application (e.g. in SAP database) so that a user can logon to SAP with a known password. If you use CUA then the idm product will have to set the users password on all SAP systems that they need to logon to, but access rules such as roles/profiles can be set only on the CUA master and CUA will sync these and other user details to other SAP systems. If you don't use CUA then the idm solution will also have to set the users password on all SAP systems. This is because CUA does not sync user passwords between systems.

So, clearly there is going to be some fun setting passwords on all SAP systems, and making sure that password changes are kept in sync etc. etc. You will find many threads in this forum where this subject is discussed, and I seem to remember Wolfgang mentioning a SAP note which highlights reasons why password sync between idm and SAP systems is not recommended.

Instead of syncing passwords, the more acceptable solution is to stop SAP from needing a password, and this is done with SAP ABAP systems via SNC. You can setup SNC to authenticate users, using external authentication methods. e.g. using Active Directory credentials issued when user logs on a their workstation using a domain account. WHen you do this the idm product can take care of adding/deleting/changing users and not have to worry about authentication/passwords - the authentication can then be handled via external authetnication, and secure protocols.

Thanks,

Tim

[WolfgangJanzen]

 Santosh,
 It looks like youa re going to have some fun !

smile

PS: it's [SAP Note 376856|https://service.sap.com/sap/support/notes/376856] you are refering to

Edited by: Wolfgang Janzen on Feb 24, 2010 9:46 PM

[WolfgangJanzen]

... the idm product can take care of adding/deleting/changing users and not have to worry about authentication/passwords - the authentication can then be handled via external authetnication, and secure protocols.

Absolutely true. Especially in a browser-based scenario SAML 2.0 will become more and more important.

The next (coming) Business Suite will support it (as SAML 2.0 Service Provider) same as SAP's own Identity Management solution (acting as SAML 2.0 Identity Provider, as well). It's worth to notice that [interoperability is key - and assured|http://www.projectliberty.org/news_events/press_releases/entrust_ibm_microsoft_novell_ping_identity_sap_and_siemens_pass_liberty_alliance_saml_2_0_interoperability_testing/].

Edited by: Wolfgang Janzen on Feb 24, 2010 9:55 PM

[Former Member]

Damn. You were faster than me, but I still want to add a comment.

Santosh et. al. are not migrating a CUA to an IdM - this migration is easily done by adding the IdM as the "front-end" to the CUA and then switching the managed systems over to direct provisioning one at a time, without stress. That is standard procedure and works.

What is being done here is to implement a CUA for the business logic of the ABAP systems and use "catching screens" as the front-end to be able to distribute the password to non-ABAP systems as well simulate a "real" IdM with a crow's nest of overhead in the background for the basis folks to take care of and maintain.

Not a good idea, and I can already see all the "catching IDocs" involved, or even the dependency on being able to do so.

Clear design error (in the year 2010) and bad investment in available technology (in the year 2010 as well).

I would go for an IdM (regardless of the vendor) with all the agents supported for current and planned systems' APIs being used (regardless of the vendor) and a standards based SSO technology compatible with the various worlds on site (as regardless as possible of the legacy vendor support).

Whether that is PSE's, Kerberos or SAML does not really matter much when decentral password synchronization is still considered as an option for human owners of system identities.

Hopefully Santosh will keep us updated, but I would also understand if this for what-ever reasons was not allowed.

My customers also dont permit me to post everything while they are still using the odd FM or two...

Cheers,

Julius

[Former Member]

Julius,

I agree with you and thanks for noting down those points. Do you have any whitepaper, or statistics or some business mumbo jumbo that discusses this area, for me to further discuss with my client?

From my perspective, when they first told me they're doing SSO, I told them it's a good idea to do an IdM solution, and so on. Then this morning's meeting revealed this screen capture strategy and that really does change the dynamic a teensy weensy bit, doesn't it.

Thanks a lot, and I will keep you guys posted on this thread as things roll out.

Santosh

[Former Member]

SAP's own IdM even also offers an (optional) password hook with the MS AD, but is optional and the IdM as front-end is a migration path for existing CUA's and not an (new) implementation strategy.

> mumbo jumbo

You can use the search for related patterns (also see the FAQ thread at the top of the forum page for memorable discussions) The terms "sorry to disagree with you" and "login/password_min_diff" and "BAPI AND password" and "weakest link" and "common denominator" are good starting ponits.

If you look about 16 threads down (current location) then you will find another good search term. You will find the vendor in other threads as well.

Cheers,

Julius

[Former Member]

ps: If they want to use one ABAP client via the CUA as UME for each logical Java system or even via a service for non-SAP systems, then you need to consider that this "workaround" has a limit of 998 clients per CUA master.

I just checked one of my clients, and they have more than 2000 Oracle based applications. Many of them are delta requirements and custom front-ends for projects (possibly like yours?) where it was a "post mortem". These also need to authenticate (somehow, or not at all...) and re-using the kerberos realm of the AD is certainly a MUCH better option.

In this case (I am originally an accountant) you would not need to worry about the IT auditors finding it actually (the password synchronization). The accountants will pick it up when the project is not closed or capitalized (should it have any real remaining value at all..) and what could or should have been operational costs are "parked" on it.

A good financial auditor would even pick this technical decision error up, even if they have no clue about IT. Perhaps I am opening a can of worms here?

Cheers,

Julius

[Former Member]

I know that I've marked this thread as answered, but who'd have guessed ... my client has successfully unanswered it.

So here's the follow on to this discussion, where in I am out of my league and need your input.

Brief overview:

ABAP boxes are managed by a CUA. users created in CUA from Oracle OIM, which is outside my control. Client wants Enterprise Portal to use CUA as the user store.

Complication: Client has been told that all users can log into Enterprise portal, and from there, click on an icon to get "whisked" into the ECC, SRM or other systems, and that single sign on can be setup to do this.

As far as I know, the setup, as described, would use the Web GUI, and beyond that I don't know. Anyway, I don't believe you can launch the SAP Logon pad and do any sort of single sign on without having an SNC installed (which they don't).

I need to get my information straightened out on SSO. If I have my BASIS team to setup SSO in EP, what is it that I can and can't do, specifically regarding SAP GUI, Web GUI, and general user access to SAP systems?

Thanks,

Santosh

[tim_alsop]

Hi,

This is actually quite easy...

When a user logs onto portal, using any method, e.g. SPNEGO, Basic Auth etc. they will be issued with an SSO2 ticket by the portal because of the CreateTicketLoginModule. The SSO2 ticket is represented as a cookie in browser. When the user then visits a link which takes them to the applications that are web based on other systems, e.g. on ABAP systems, the SSO2 ticket is sent to these systems as a cookie, and if they are trusted, the other system will know the SAP id of the logged on user. This allows a user to logon to protal and then click on a link and be taken to webgui without having to logon again.

For SAP GUI, this is not normally using SSO2, so SNC is required. If a user then logs on to SAP ABAP system using SAP GUI, they can be authenticated as the same user as if they were to logon to the Portal, as long as the SSO technology used for portal and SNC auth is same. Most companies use Kerberos for this, since Active DIrectory uses Kerberos to authenticate users when they logon to workstation. The user logs onto their AD domain, and then can logon to SAP systems via SAP GUI or Web browser and be recognised as the exact same SAP user, which is based on the AD account they logged onto their workstation with.

I told you it is easy !

Thanks,

Tim

[WolfgangJanzen]

For SAP GUI, this is not normally using SSO2, so SNC is required. 

To my knowledge, the SAP Enterprise Portal (EP) does offer a method (see. Portal Application Integrator) to launch "SAPGUI iViews". This works technically by using SAPshortcut as MIME application (a technique which was originally developed for the SAP Workplace 2.11) transmitting SAP Logon Tickets via DIAG protocol.

[Former Member]

Hello Santosh,

Please see [Single Sign-On for SAP Shortcuts|http://help.sap.com/saphelp_nwmobile71/helpdata/en/43/e0499e421a4d9de10000000a155369/frameset.htm] which uses SAP logon cookies provided by Portal to the SAP GUI. We can also help you SSO via SNC. If your users are all access SAP GUI from the portal then the advantage you would see using SNC is network traffic signing and encryption versus clear text communications.

Thanks!

Kyle

[tim_alsop]

>

> To my knowledge, the SAP Enterprise Portal (EP) does offer a method (see. Portal Application Integrator) to launch "SAPGUI iViews". This works technically by using SAPshortcut as MIME application (a technique which was originally developed for the SAP Workplace 2.11) transmitting SAP Logon Tickets via DIAG protocol.

Yes, this is why I said "normally using". This option is available, but I have not found many companies use it becasue of the security issues. When an SSO2 ticket is sent to a server by SAP GUI, this can be intercepted and is therefore not secure. To improve this you need to enable SNC, and if you enable SNC then you can't use SSO2, since SNC handles the authentication.

Also, if you use SNC with SAP GUI and not browser invoking shortcut approach, then the user can logon to their workstation and use SAP GUI and doesn't need to logon to portal first.

Thanks,

Tim

[WolfgangJanzen]

When an SSO2 ticket is sent to a server by SAP GUI, this can be intercepted and is therefore not secure. To improve this you need to enable SNC, and if you enable SNC then you can't use SSO2, since SNC handles the authentication. 
Also, if you use SNC with SAP GUI and not browser invoking shortcut approach, then the user can logon to their workstation and use SAP GUI and doesn't need to logon to portal first.

I (personally) fully agree with you.

But you know: some customers are demanding such features - some even demand stupid features like "password synchronization" (instead of a proper, robust and secure Single Sign-On solution). Well, we both certainly agree that this is non-sense - but as long as there is demand for such "solutions" there is business (revenue, ...).

[Former Member]

Thanks Kyle. Even though it wasn't me who implemented the solution, it was this link that got our SRM guy to get cracking on how to go about this. So now, we have it setup so that within Portal, there's an icon for SAP GUI, and that pops up a proper SAP LOGON window, as my client is demanding.

Thanks.

Santosh

[Former Member]

> there's an icon for SAP GUI, and that pops up a proper SAP LOGON window, as my client is demanding.

It is just a little popup window, right?

And if the user is already logged on then clicking on the icon (or executing the shortcut) does not present the logon popup, right?

A risk here is that the user is accustomed to enter their passwords into popups which appear and when things just run on their own then they think nothing of it...

@ Wolfgang and Tim:

Two solutions to the general comments I can think of are:

1) The vendor's Corporate Governance should kick in to say "That is enough stupidity" and it is not the strategic product direction (not to mention security image... with all non-short term consequences for revenue) which the software manufacturer wants to take and support.

2) The security research community gives admins 90 days grace, and then publishes the exploits. If an entire infrastructure is kept dependent on it via support or "hole in the bucket" integration encouraged by it, then it gets worse and worse and customers dig a deeper and deeper hole.

Personally, I would go for option 1 if it were my call.

Cheers,

Julius

[MichaelShea]

Hi Santosh,

This is what we say in the documentation about integrating with CUA.

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/74/642441cd87a12be10000000a1550b0/frameset.htm

As Julius said, though, SAP NetWeaver Identity Management is the way to go in the future, rather than CUA. You can integrate SAP and non SAP systems. You do not mention what non SAP SSO you are using. Can you clarify?

-Michael

[Former Member]

The client successfully found a way to unresolve this resolved issue.