Access restrictions on Portal-R3-Single-Sign-On

[Former Member]

Hello,

i installed a NetWeaver 2004s Java Portal System (upgraded to SP10) and a Solution-Manager 4.0 System (upraged to SP8) on the same Windows 2003 Server for testing purposes. I deactivated the Java-Stack in the Solution-Manager in order to keep both systems running at the same time (otherwise i get error messages from the java virtual machine). I managed to access the Solution-Manager-ABAP-System via the integrated ITS through the portal and i implemented Single-Sign-On between both systems.

Is it possible to restrict this Single-Sign-On-Access? For example, i have a Solution-Manager-User called VIP (and a corresponding Portal user VIP) and it shoudln't be possible to access the Solution-Manager with this user using Single-Sign-On. If the VIP opens the SAP-Transaction-IView in the portal the login screen should appear so that the VIP-User has to enter his Solution-Manager-Password. Every other user should be able to directly access the SAP-Transaction.

[WolfgangJanzen · Accepted solution]

Assuming that you are using SAP Logon Tickets for SSO the answer is: No - it is not possible to control the ability to use SAP Logon Tickets for authentication on a per-user base.

Advice: rename the ABAP user "VIP" to "_VIP" and make sure that no such user ("_VIP") exists in the Enterprise Portal. The SAP Logon Ticket (created by EP) then contains "VIP" as userID which refers to a non-existing ABAP user. Therefore the logon attempt will fail and the ABAP system will prompt you for password-based authentication. If I got your right, then that's what you want to achieve.

Cheers, Wolfgang

[Former Member · Accepted solution]

Sorry, i didn't mention my real goal.

The problem is that the administrator of the Portal UME has then access to all the data of the SAP R/3 system. He only has to create a user with the specific rights in the Portal UME. Then he is able to connect to the R/3 system as this user using the portal. Therefore the administrator of the portal UME must be the same person that adminsters the SAP R/3 users or at least a person that has the same level of trust.

[WolfgangJanzen · Accepted solution]

Well, that's an instrinsic problem:

if you've configured the SAP R/3 system (aka "NetWeaver Application Server ABAP" or NWAS ABAP) to trust the SAP Enterprise Portal (aka EP) then this means that the NWAS ABAP has delegated the user authentication to the EP: EP verifies the user's credentials and issues an assertion (here: an SAP Logon Ticket) in case of a successful result.

Theoretically, one could deploy his own JAAS login module on the EP which does not perform a proper authentication but simply returns the result "user X has been authenticated, please create a SAP logon ticket for that user". Well, being able to deploy own JAAS login modules is comparable to being able to modify a LINUX kernel ... - applications will have to trust the underlying framework.

Please keep in mind: one major concept of EP is: it is the central entry point (therefore called "portal"); user's get authenticated at the EP and will be granted access in the entire portal system landscape (according to their roles which define their authorization assignments in the backend systems). It's pretty similiar to a domain controler - you can only join or don't join (but nothing in-between).

Cheers, Wolfgang

[Former Member · Accepted solution]

That's interesting. At the moment I'm analysing the SAP.Net-Connector in combination with Single-Sign-On and the MYSAPSSO2 logon ticket. And a minute before I thought about the same aspects.

If the SAP.Net-Connector works as i expect a programmer that deploys an ASP.Net application that uses the ticket toolkit and therefore the portal certificate could misuse the SAP R/3 account of every person that uses his application.

[WolfgangJanzen · Accepted solution]

Well, it's all about trust.

Keep in mind: the assertion (here: SAP Logon Ticket) is digitally signed which allows to validate its integrity as well as to authenticate the issuer. Its then up to the recipient to trust or not to trust. In addition to the verification of the digital signature the recipient shall also perform an ACL (access control list) lookup and check the assertion's lifetime validity.

Be fair: when accepting SAML assertions or Kerberos tokens you also have to trust the issuer.

<a href="http://de.wikipedia.org/wiki/Ex_falso_sequitur_quodlibet">Ex falso quodlibet</a> - or "you can conclude anything based on wrong assumptions". Here: you should not trust the wrong ones.

[Former Member · Accepted solution]

Yes, i admit.

[tim_alsop · Accepted solution]

It seems to me that this is a case of confusion between authenication and authorisation (or access control). I will try and explain ...

When a user authenticates, depending on the authentication technology used, a token of some sort is issued, which is nothing more than something to show that the user has authenticated. This token is like "a passport", that shows the user has successfully authenticated. In the real world, if I present my passport to somebody at an airport they are able to look at it and use it to determine my real identity, then they can decide whether I am allowed to enter the airport to board an airoplane. So, the decision to allow access is not using authentication technology, it is an authorisation decision based on the trust of my authenticated identity.

So, if we relate the above example to your situation - the fact the user has been able to authenticate, and has an SSO2 logon ticket means that they can pass this ticket to any SAP application - the SAP application needs to determine if the user is allowed access, and if so, what level of access they will be granted.

I hope this helps ?

Tim

[Former Member · Accepted solution]

Yap, thank you very much.

[WolfgangJanzen · Accepted solution]

Sorry to disagree - "authentication" and "authorization" are clearly defined. Well, me might argue on "identification" versus "authentication" - but I'm afraid that all others might feel bored, then.

Access to business functions is granted based on "authorizations" (aka "roles"), e.g. the questions "Is this user authorized to gain read access to that document?" and "Is this user allowed to change the salary of user ...?" fall into that category.

Access to systems is granted based on "authentication" ("Who is that user?").

Well, "authentication" is a prerequisite for "authorization (checks)".

Regards, Wolfgang

PS: your passport example refers to that "identification" versus "authentication" issue ... - frankly speaking: the border official can only verify your passport and compare the passport picture with your appearance - but they cannot determine your real identity ...

[tim_alsop · Accepted solution]

Wolfgang,

Yes, you are right. It seems I mixed "identification" and "authentication" when attempting to explain the differences. I think I need a holiday

Cheers,

Tim