views:

390

answers:

3

I work in a large company, and I'm interested in best practices for internal security standards. We have a large ($500 million +) investment in SAP, and we also have .Net and a bit of JEE in our internal environment.

I've found some documentation from MS and SAP, but it's outdated and not very specific.

So far, it looks like we could end up using Active Directory as the standard user store for all non-SAP applications, and SAP CUA / Portal for SAP applications.

Some concerns I have about AD are:

  • Being able to aggressively time-out for applications on shared computers (A small number of our applications run in remote offices in rural areas with a limited number of shared machines. In these cases, a supervisor with "power user" privilages could use an application, and then a clerk who should have only basic privaleges could use the same machine immediately after)

  • Being able to force the user to enter a username and password instead of just having the credentials read from the user's workstation - Because it's pulling the same credentials for the desktop and email, it won't currently ask users to log in. This is a concern for applications on shared computers as well. (See the explanation in the previous bullet)

    As far as synchronization between AD and CUA is concerned, I want to approach this very carefully. We have a limited budget, and I want to make sure that if we end up putting something in place to synchronize the stores, that it's rock sold and provides excellent value. If we can't find something like this, I'd be comfortable coming back with a recommendation that the stores remain independent. SSO would be ideal, but I've worked with trying to get an SSO application up before SAML, and it wasn't pretty.

Acronyms:

  • SSO: Single Sign-On SAML: Security

  • Assertion Markup Language

  • CUA: Central User Administration (For SAP)

+1  A: 

Why is it a problem if users don't have to log in? Wouldn't that be more convenient for users? And wouldn't it give them further incentive to log out of the application?

The project I'm working on now uses AD, and we have a mapping table inside of SAP to map AD accounts and SAP accounts. Syncronisation is manual, which may or may not work for you, but there's no real technical risk.

I wish I could give you more information, but I haven't been very involved with that side of things. I can look into it,though.

Travis
Hi Travis, A small number of our applications run in remote offices in rural areas with a limited number of shared machines. In these cases, a supervisor with "power user" privilages could use an application, and then a clerk who should have only basic privaleges could use the same machine.
Kaiser Advisor
+2  A: 

Hi

There is a lot of possibilities on this subject.

We had a customer that updated both their AD and their SAP user list from SAP HR. The idea was that the OM module contained all employees. You could export daily a list of all active employees to the LDAP, with basic informations (firstname, lastname, employeeId, login...). For the SAP system, unit/function/job needing a sap access where tagged and user where created/removed daily.

In fact, all employees had a SAP account, but only those tagged had a "dialog" one. Those account are allowed to connect via SAPGUI, others had to use the portal, which is a less costly licence. A set of rules allowed to set the roles for the managed users. The goal was to minimize user management and limit the inexorable grows of autorisation that comme from moving from job to job an organisation. (this was for 105000 employe, with a lot of personnel movement).

Thus SAP was not directly linked to the AD, but they where synchronised. Depending on the system (Development, qulity, integration, production), SAP was configured with time-out. You could also have différent password for separate systems.

Of course the reverse is also possible : interrogate a LDAP from SAP to manage SAP's accounts, without beeing directly linked to the LDAP. transaction LDAP can problably give you some informations.

hope this helps

Edit : the synchronisation was done by an ABAP program. that program was run every day at four, and created/deleted/modifed some accounts in the LDAP. After that, another program added some technical informations to the LDAP entries, informations that where not available to the SAP RH system (such as the mail server to use for a given employee, depending on its location around the world). The entries where then checked for consistency, and send to the master LDAP.

This program only managed personnel and units. Groups (authorization for others application) where managed either manually, or by others programs. Thus non SAP data were also stored in the LDAP.

Regards

PATRY
Bonjour Patry, This is very intersting. Did you use some sort of a product to help with the synchronization from SAP HR to AD? Did you use AD as the standard store from non-SAP applications?
Kaiser Advisor
Hey Patry, is there any way I could contact you to ask some more detailed questions? I'm very interested in how this is set up, as I'm trying to do the exact same thing.
Kaiser Advisor
I sent you a mail on the address given in you blog, with my contact.Regards
PATRY
+1  A: 

You might want to look at OpenSSO - it has agents for SAP and it will integrate with AD as the user store. It's also pretty solid - Verizon use it for 40 million customers to log in to their web site.

metadaddy