1 2 3 5 Previous Next

Security

62 Posts

Hello Experts,

 

I am going to perform security upgrade from 4.6B to ECC6.0. Below is my analysis in the system 4.6B.

Aaround 5000 Manual profiles and 2700 Roles are there in the system. Also 3000 custom t-codes & 180 custom objects are there. I don't have experience on Manual Profiles. Here is my questions.

 

1. Could you please let me know how to down load list of Manual profiles in the system?I checked in SUIM..here it's showing Manual profiles & profiles assigned in the roles.

2. How to check existing t-codes in manual profiles? I have checked in SUIM-->Transactions executable in profiles, but here it's not allowing to select multiple selection of profiles.

3.Also please let me how to check Org values & Objects in Manual profiles?

 

Please let me know if any tables or any other way to check the same.

 

For example in roles we have tables like AGR_TCODES, AGR_1251 & AGR_1252..kindly let know the same as Manual profiles.

 

Thanks in advance for your help.

 

Regards,

Sudhakar

Disclaimer: this prototype is far from production ready due to various reasons. It still shows what you can do when you have a biscuit recipe. It was also fun to do. All development was done in Netweaver version 7.31.
I really like new Mozilla Persona. It could be really nice to outsource authentication to some 3rd party in some scenarios (e.g. non-employees log on to your system). You don't have to store any passwords. If identity provider supports two-factor authentication then you get it for free.  At this early stage you have to trust Mozilla (IMO much more trustworthy than Facebook or Google) but it's a decentralized solution similar to email. So in future you can run your own corporate identity provider for internal employees. Definitely check the Mozilla pages for more information about Persona. I am going to concentrate more on SAP side.

Challenge

 

The Mozilla guys claim that you can add Mozilla Persona to your app in a single afternoon. So I tried to do the same for ABAP AS. I followed the quick setup from Mozilla. It has only 5 steps:
  1. Include the Persona JavaScript library on your pages.
  2. Add “login” and “logout” buttons.
  3. Watch for login and logout actions.
  4. Verify the user's credentials.
  5. Review best practices.
Note #1 – I did not bother with log out. There is a small issue with implementing log out but not a big one.
Note #2 – I did not bother with step 5 J As you will see it's not the nicest implementation. But hey, I've seen much worse code in production and this is just a prototype.
Note #3 – IE compatibility mode breaks Persona. As far as I know web dynpro for ABAP requires compatibility mode. Hence I did my testing in Firefox.
Basically, you can split changes into two groups: UI changes and backend authentication service.

Logon Screen Enhancement

 

The first 3 steps are related to client. So we need to include some javascript and add a button for signing in with Mozilla Persona. So I copied standard logon class CL_ICF_NW07_LOGIN and called it ZCL_PERSONA_LOGON. I modified method HTM_LOGIN to include 2 javascript libraries (Persona and jQuery). I misused variable hidden fields to add a simple HTML fragment to include javascript libraries. I used Google to host jQuery for me. jQuery is not mandatory but I liked the code with it more.
CONCATENATE
 iv_hidden_fields
 '<script src="https://login.persona.org/include.js"></script>'
 '<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js"></script>'
 INTO new_hidden.
I also used method HTM_LOGIN to add javascript code defined in step 3. In this case I misused javascript variable. I added the following lines to it.
CONCATENATE
 'var signinLink = document.getElementById(''SL2'');'
 'if (signinLink) { signinLink.onclick = function() { navigator.id.request();};}'
 'var currentUser = ''bob@example.com'';'
 'navigator.id.watch({'
 'loggedInUser: currentUser,'
 'onlogin: function(assertion) {'
 '$.ajax({ type: ''POST'', url: ''/persona/login'', data: {assertion: assertion},'
 'success: function(res, status, xhr) { window.location.reload(); },'
 'error: function(xhr, status, err) { alert("Persona Failed");navigator.id.logout(); }'
 '});},'
 'onlogout: function() {'
 '$.ajax({type: ''POST'', url: ''/auth/logout'','
 'success: function(res, status, xhr) { window.location.reload(); },'
 'error: function(xhr, status, err) {}'
 '});}'
 '});'
 iv_javascript INTO new_javascript.
The last change which I made to logon class was to add a custom link for signing in with Persona. This can be done in method ADD_CUSTOM_LINKS.
METHOD add_custom_links.                                    "#EC NEEDED
 DATA link LIKE LINE OF links.
 
 link-text = 'Sign in Mozilla Persona'.
 link-href = '#'.
 APPEND link TO links.
 ENDMETHOD.
So I was able to do required UI changes really quickly. I changed configuration of one web dynpro app in transaction SICF to test this. I got the following logon screen.
pic1.png

Verifying Credentials

 

The second big chunk of work is implementing a backend service that validates an assertion ticket provided by client. This assertion ticket is received by client from identity provider. I implemented this service as a bespoke HTTP handler assigned to URL /persona/login (see above that this URL is called from javascript function that is registered for event onlogin).

 

pic2.png

 

An implementation is straight forward.

 

METHOD if_http_extension~handle_request.
 DATA: assertion TYPE string,
 persona TYPE REF TO zcl_persona,
 ret TYPE i,
 email TYPE string,
 host TYPE string,
 port TYPE string,
 prot TYPE string,
 audience TYPE string,
 biscuit TYPE REF TO zcl_biscuit,
 ticket TYPE string.
 
 * Set HTTP code to 500
 server->response->set_status( EXPORTING code = 500 reason = space ).
 
 * Allow only POST
 * XXX
 
 * Get hostname
 server->get_location( EXPORTING protocol = 'HTTPS' IMPORTING host = host port = port out_protocol = prot ).
 CONCATENATE prot '://' host ':' port INTO audience.
 
 * Get and validate assertion ticket
 assertion = server->request->get_form_field_cs( 'assertion' ).
 
 * Validate assertion ticket
 persona = zcl_persona=>get_persona( 'PERSONA' ).
 persona->validate_assertion( EXPORTING assertion = assertion audience  = audience
 IMPORTING ret = ret email = email ).
 CHECK ret EQ 0.
 
 * Map email to user
 * XXX
 
 * Generate cookie
 biscuit = zcl_biscuit=>get_biscuit( ).
 ticket = biscuit->get_ticket( 'MARTIN' ).
 
 server->response->set_cookie( name = 'MYSAPSSO2' path = '/' value = ticket ).
 server->response->set_status( EXPORTING code = 200 reason = space ).
 
 ENDMETHOD.

 

This service must return 200 when validation is successful. So the first think what it does is that it sets return code to 500. If anything fails then a user won't be authenticated. As I said above I outsourced everything to Mozilla. So it uses Mozilla verification service to validate assertion. I'll explain it bit more in the next section. It's really simple. You pass only 2 parameters to this service: assertion that comes from client as POST parameter and audience that must be same as client's URL. If assertion from client is correct then I map an email address returned by verification service (not implemented above, mapping should also check if user is locked) and generate a SSO cookie using class from project Biscuit. A return code is set to 200 and a cookie is sent back to user.

 

Assertion Validation

 

 

So the last step is to verify assertion received from client.  As I mentioned above I used Mozilla verification service. You perform a POST request with two parameters (assertion and audience) and it returns a JSON document. An implementation in ABAP looks something like this.

 

DATA: client TYPE REF TO if_http_client,
 http_code TYPE i,
 data TYPE string,
 dest TYPE c LENGTH 20,
 bhole TYPE string,
 str TYPE string.
 
 * Use Mozilla service to validate assertion
 dest = me->rfc.
 cl_http_client=>create_by_destination( EXPORTING destination = dest
 IMPORTING client = client ).
 client->request->set_method( if_http_request=>co_request_method_post ).
 
 * Set assertion & audience
 client->request->if_http_entity~set_form_field(
 name   = 'assertion'
 value  = assertion ).
 
 client->request->if_http_entity~set_form_field(
 name   = 'audience'
 value  = audience ).
 
 client->send(
 EXCEPTIONS
 http_communication_failure = 1
 http_invalid_state         = 2
 http_processing_failed     = 3
 http_invalid_timeout       = 4
 OTHERS                     = 5 ).
 
 IF sy-subrc <> 0.
 * Connection failed
 ret = 1.
 RETURN.
 ENDIF.
 
 client->receive(
 EXCEPTIONS
 http_communication_failure = 1
 http_invalid_state         = 2
 http_processing_failed     = 3
 OTHERS                     = 4 ).
 
 IF sy-subrc <> 0.
 * Connection failed
 ret = 2.
 RETURN.
 ENDIF.
 
 client->response->get_status( IMPORTING code = http_code ).
 IF http_code <> 200.
 ret = 3.
 RETURN.
 ENDIF.
 
 data = client->response->get_cdata( ).
 
 * Very ugly and stupid validation. Good enough for prototype
 IF data(17) CS '{"status":"okay",'.
 * All good, retrieve email address
 * XXX
     ret = 0.
 ELSE.
 ret = 4.
 RETURN.
 ENDIF.

 

I also had to import Mozilla certificate into STRUST. Otherwise ABAP AS refuses connecting to Mozilla server.

 

How it looks?

 

Enough of ABAP code. Here is how it looks when you try to sign in with Persona to ABAP AS. At this moment only Yahoo implements Persona. For other email providers you need to create a Persona account with Mozilla that will be used for authentication. Mozilla will only store your email address and password. I used my Yahoo account for this demonstration.

 

After clicking on link Sign in Mozilla Persona you get a Persona pop up window. Because I've never used Mozilla Persona before on this computer there is no email address. It tells what you need to do but it's simple. In my case I need to enter my Yahoo email address.

pic3.png

 

So after entering my Yahoo email address I am redirected to Yahoo to authenticate.

 

pic4.png

 

 

 

After successful authentication with my Yahoo account I am redirected back to Persona.

 

Note: if I activated 2-factor authentication for this Yahoo email then I would sign in into ABAP AS using 2-factor authentication.

 

pic5.png

 

After this the pop up gets closed and web browser calls backend service /persona/login. It passes the assertion ticket to it. If this service returns HTTP code 200 Persona reloads the web page. At this moment my browser received MYSAPSSO2 cookie for a user mapped from email address from /persona/login. Hence reloading page displays a web dynpro application instead of logon screen. I logged on to ABAP AS without entering my SAP username and password. If I was already logged to my Yahoo email then I would not have to enter any password.

 

That's it. All kudos go to Mozilla guys. I am really impressed with their execution. I cut some corners (mapping, error handling) but it took me only 3 hours and 40 minutes to build this prototype. Roughly the same time as posting this blog post :-)

 

Martin Voros

Baking Biscuits

Posted by Martin Voros Apr 11, 2013

Java AS has a nice capability of using a custom logon module. This allows you to use alternative methods to authenticate users. A nice technical example is to use Facebook Connect as an alternative method for authentication. Check this blog for more information on how to do it on Java stack.

 

Unfortunately, ABAP AS does not have this capability. I hit this limitation many times before. You can have a custom HTTP handler running under service user but there is no way of switching from service user to different user. One workaround is redirecting to Java AS, perform authentication there, generate a SSO cookie and then redirect back to ABAP AS. I was still hoping for a solution that does not require Java AS. You could use same trick on ABAP AS stack if you could generate SSO cookie for any user. You can get a cookie only for current user. SAP does not provide library for generating SSO cookies. There is a library called SAPSSOEXT that gives you capability of validating SSO cookies. So you can use SAP SSO cookies in external apps for authentication.

 

Recipe

 

It's really funny that it's never occurred to me that it should not be hard to reconstruct SSO ticket structure. I knew that each cookie is digitally signed. Finally, I tried it this week and it wasn't hard at all. SAP SSO ticket has a simple structure and now when I think about it it's obvious. It's just a list of values that are digitally signed. Basically, it is composed of a ticket header and multiple pairs: field header and field value.  Here is my recipe for it.

 

SSO Structure:

Ticket Header

Field Header

Field Value

Field Header

Field Value

……

Field Header

Field Value

 

Note that the following examples of field values are in hexadecimal format and this is not a full spec of SSO format.

 

The ticket header has only two fields: version and code page used for the field values.

Field Name

Length

Description

Version

1 byte

Always x02 (even cookie is called MYSAPSSO2)

Code page

4 bytes

Unicode systems seem to use code page 4102 that corresponds to UTF-16BE. It means that there will be two bytes for each character. Hence you can see value x34313032

 

The field header has two fields: field ID and length of value.

Field Name

Length

Description

Field ID

1 byte

  1. E.g. ID x01 corresponds to field username

Length

2 bytes

  1. E.g. x0018 is a length for field username. Username in ABAP AS is 12 characters long and UTF16 has 2 bytes for each character. Hence for this field there will be 24 bytes (x18).

 

The field value is just a stream of bytes with length defined in corresponding field header. The field ID is only one byte. Therefore we can have 256 different field IDs. I've seen various field IDs. I haven't figured out meaning of all of them. Also a cookie generated by Java AS has more fields than one generated by ABAP AS. But not all fields are mandatory. Here is a list of required fields for generating a valid SSO ticket that is accepted by ABAP AS.

 

Field ID

Length (code page 4102)

Description

1

24 bytes

Username

2

6 bytes

Client of issuing system

3

16 bytes

Issuing system ID

4

24 bytes

UTC Creation date and time without seconds

5

4 bytes

Validity in hours

255

Variable, length of digital signature.

Digital signature of all cookie in PKCS#7 format

 

It's quite easy to generate SSO cookie in any programming language.  You just need to have a crypto library that can sign binary data using PCKS#7 format.

 

Here is SSO cookie generation in 3 simple steps:

  1. Generate binary data in format described above (do not include field 255 – digital signature)
  2. Sign generated data with private key of certificate that is used for validating SSO tickets
  3. Append field 255 with value set to digital signature to binary data.

 

Don't forget that creation date and time must be in UTC. Otherwise it can drive you crazy when something works ½ day and it does not the other half (ratio of working/not working depends on your time zone).

 

I wrote my own implementation in ABAP (I told you that I wanted to have implementation without Java and using OS commands is not a nice solution). It's hosted on Code Exchange as Project Biscuit. It's a simple ABAP class but I could not find a better place for it than Code Exchange. Usage of this class is dead simple. It takes only 5 lines including variable definitions to get a valid cookie.

 

DATA: biscuit TYPE REF TO zcl_biscuit,
     ticket
TYPE string.

biscuit
= zcl_biscuit=>get_biscuit( ).
ticket
= biscuit->get_ticket( 'MARTIN' ).

 

Some final thoughts

 

What was my motivation to figure this out? Just recently I’ve seen a presentation about new Mozilla Persona. I really like this solution of distributed identity providers. The presenter claimed that you can include Mozilla Persona into your application in less than 4 hours. I wanted to test if it's also true for ABAP AS. I knew that I really needed to solve this authentication issue first. If anybody is wondering, yes it takes less than 4 hours to build a Mozilla Persona prototype in ABAP AS.

 

Why SAP does not provide a library to generate SSO cookies? I don't know. My guess is that as usual it's a mix of various reasons. Inexperienced developers can cause lots of harm by implementing custom logon procedures. You can also do lots of shady things to avoid licensing cost with this.

 

Final note about name: I was told that here in Australia we don't have cookies, we have biscuits. Hence the names of class, project and this blog post.

Someone asked me about Uflag value in table USR02 and of course I knew the most common ones but he asked me about values I had never seen like 1 - 33- 97 (so regular values +1).

 

In the help of the system we only can see this, it was fast and easy to understand that 96 came from 32 + 64 and so on. But I had no idea about the +1 !

uflag.png

 

User status

Reason

0

User not locked

32 (Hex 20)

Locked by CUA central administrator

64 (Hex 40)

Locked by administrator

128 (Hex 80)

Locked after failed logon

192

Locked by administrator + Locked after failed logon

96

Locked by CUA central administrator + Locked after failed logon

160

Locked by CUA central administrator + Locked after failed logon

 

I googled it for 30 minutes but didn't find a clear answer, so I asked my colleagues who didn't know neither.

I finally asked my boss, who worked for SAP BC Team and has a good knowledge about SAP.

Here is the explanation about the 1 value !

 

When SAP BC team locks the users to do their job (maintenance, upgrade or whathever), they use a program to add 1 in the Uflag. So when they have to unlock the users they know which ones they locked and which ones were already locked by admin or other reasons.

So when they have finished their job, they launch another program to do -1 to Uflag. So logically, if the job is correctly done, the results is always equal to the figures from the table above.

 

It can happen that the administrator does the unlock before SAP BC, so the calculation is : +64 locked by admin +1 locked by BC -64 unlocked by admin which gives 1

Another example : user locked by CUA + administrator + BC Team : 32 + 64 + 1 ==> 97

For a reason or another the -1 work is not performed so the values are addioned by 1.

 

This rule can be applied to all values.

 

 

Nicolas.

The German SAP User Group (DSAG) recently released a best practices guideline for ABAP development*. It provides valuable technical content mixed with practical recommendations how to set up and maintain a process for "ABAP quality". This new guideline for the first time delivers a holistic view on ABAP development.

 

"Security & Compliance" is covered with its own chapter, alongside "common" ABAP quality chapters (such as performance, robustness, documentation and naming conventions).

The guideline points out that security vulnerabilities caused by poor ABAP code not only put a company's IP and reputation at risk, but can also have compliance implications. The guideline points to the BIZEC APP/11** standard - the most dangerous and most common security defects observed in ABAP code - in order to given companies an idea which security tests to cover at minimum in an ABAP security project / guideline.

 

The DSAG guideline also describes how to establish ABAP quality standards in a company and how a QA process should be set up. I like to highlight the best practice "Companies should not define requirements that cannot be automatically checked for compliance by a tool". Because only requirements that can be checked will ensure user acceptance and the success of a QA standard.

 

All in all a great 360° overview of ABAP code quality and security best practices, that enable quality-minded companies and organizations to build ABAP development strategies that are (and stay) state-of-the-art. Unfortunately (for some) it is only available in German at present. But if you ever wondered, why you should learn German: here is a reason...

 

 

* http://www.dsag.de/fileadmin/media/Leitfaeden/Best-Practice-Leitfaden-Development-Flash-Book

** http://www.bizec.org/wiki/BIZEC_APP11

Topics:

  1. Introduction
  2. Security Contact
  3. Update Kernel according to notes 1785761 and 1800603
  4. Mitigation, workaround, best-practice for Kernel update
  5. RFC Security in general
  6. Message Server security in general

 

 

1. Introduction

 

SAP published two HotNews security notes about the kernel in February 2013.

 

Note 1785761 - Missing authorization check in RFC

https://service.sap.com/sap/support/notes/1785761

CVSS Base Score: 9.0
CVSS Base Vector: AV:N/AC:L/AU:S/C:C/I:C/A:C

 

Note 1800603 - Potential remote code execution in Message Server

https://service.sap.com/sap/support/notes/1800603

CVSS Base Score: 10.0
CVSS Base Vector: AV:N/AC:L/AU:N/C:C/I:C/A:C

 

This documentations shows best-practices about preparing and implementing the corrections.

Stay tuned to receives updates as we are going to extend this document from time to time. 

 

 

2. Security Contact

 

Please register yourself as security contact for your organization in the SAP Service Marketplace database.

https://service.sap.com/securitycontacts

 

As such SAP knows that you are a dedicated contact for security-related news and you will receive Ad-hoc SAP Product Security Notifications. Those are send out for very important security-related news.

 

There are two ways of registering yourself as security contact:

  • You can contact the SAP Super Administrator of your company and request to get the required authorizations to become a security contact.
    http://service.sap.com/myprofile -> Display my Super and User Administrators
  • You can create a Customer Message in the XX-SER-SAPSMP-USR component requesting further help.
    https://service.sap.com/message

 

SAP Super Administrators can remove their security contact role once they nominate another user as security contact.

 

 

3. Summary: Update Kernel according to notes 1785761 and 1800603

 

You can cover both notes by upgrading the Kernel (disp+work and msg_server) at least to following patch levels:

SAP KERNEL 7.20  patch 402
SAP KERNEL 7.21  patch 42
SAP KERNEL 7.38  patch 7
SAP KERNEL 8.04  patch 27

 

Keep in mind that both system types, ABAP and Java, contain a message server and are therefore affected.

 

If you are still running a kernel or message server on release 7.00, 7.01, 7.10, or 7.11 SAP strongly recommend to upgrade the kernel to release 7.20.  Note 1636252 describes how to install the downward-compatible kernel:

 

Note 1636252 Installing a 7.20 kernel in SAP Web AS 7.00/7.01/7.10/7.11

https://service.sap.com/sap/support/notes/1636252

 

Older release up and including 6.40 are not affected by the issue.

 

 

4. Details: Information, mitigation, workaround, best-practice for Kernel update

 

a) Note 1800603 BC-CST-MS - Potential remote code execution in Message Server

 

SAP treats this vulnerability as very critical (CVSS Base Score = 10, Priority = HotNews) mainly because of the following:

 

To solve the issue it is sufficient to update the message server file msg_server.exe (Windows) respective msg_server (others) !

 

Keep in mind that both system types, ABAP and Java, contain a message server and are therefore affected.

 

It does not matter which path (via ABAP or via Java) you follow on the Service Marketplace (http://service.sap.com/swdc) to find the patch file SAPEXE.SAR containing the message server. Just check to get the right version (for release 7.20: patch >= 402).

 

Here is the direct link for ABAP:

-> … ->

SAPEXE_402-10007259.SAR Kernel Part I (for Basis 720/702) 

 

The info file shows the note:

[...]
( 0.401) VMC: check shared GC number during cloning (note 1793845)
( 0.401) ALV Gridview: signal 8, division by zero (note 1807939)
( 0.402) Potential remote code execution in Message Server (note 1800603)
( 0.402) Rolling Kernel Switch: endless loop in message server (note 1810932)
[...]

 

You can use the message server from 7.20 for a system with a kernel running on 7.00, 7.01, 7.10, or 7.11, however, although this will work from a technical point of view it is not officially supported by SAP.

 

If you just update the message server keeping the main part of the kernel, the EarlyWatch Alert / RSECNOTE will keep on showing an alert for ABAP systems concerning note 1800603. Unfortunately the EarlyWatch Alert / RSECNOTE can only check the patch of the main part of the kernel (disp+work) but not the patch of the message server (msg_server). The tool simply assumes, that both parts are on the same level. Therefore we suggest that after verifying the patch of the message server you can set the recommendation within RSECNOTE manually to green. This manual setting is used by the EarlyWatch Alert later on.

 

Show patch level of main part of Kernel (disp+work):
Transaction SM51 -> Goto -> Server Name -> Information -> Release Notes

Another option is to execute disp+work.exe -v on operation system level (or in report RSBDCOS0).

 

Show patch level of Message Server (msg_server):
Transaction SMMS -> -> Goto -> Release Notes

Another options are to submit report RSMONREL_ALV or to execute msg_server.exe -v on operation system level (or in report RSBDCOS0).

 

Show patch level of Gateway (not relevant here, just to be complete):
Transaction SMGW -> Goto -> Release Notes

 

 

b) Note 1785761 BC-MID-RFC - Missing authorization check in RFC

 

SAP treats this vulnerability as very critical (CVSS Base Score = 9, Priority = HotNews) mainly because of the following:

  • Usually many or most of all employees of a company have network access and user accounts to connect to business systems because of employee self-services
  • Without a strong authorization concept concerning remote access via RFC, potential attackers have many options to prepare an attack

 

A system is only affected if the ABAP software component SAP_BASIS has release 7.00 or 7.01 and  the kernel (disp+work) runs on 7.20 or 7.21.

 

There is no workaround: To solve the issue you have to update the kernel.

 

The correction restores the normal authorization check for remote access based on authorization object S_RFC.

The note is mainly important if you have implemented a strong authorization concept concerning S_RFC – which is strongly recommended by SAP.

On the other hand: If you have been lazy concerning S_RFC in the past, e.g. if all or most employees have full access anyway (S_RFC with FUGR=*), that you first should do your homework on the authorization concept.

 

SAP recommends careful testing of RFC scenarios because the following could have happened: Let’s assume you are using the affected combination of ABAP and kernel for while now. If you have implemented new RFC scenarios in the meantime, this could mean that you don’t have provided proper authorizations for S_RFC without noticing it. With the upgrade of the kernel these remote scenarios could fail.

 

You find more information about RFC security in the next chapter including tips and tricks how to use the workload statistics to analyze RFC calls before (to validate the authorizations for S_RFC) and after the upgrade of the kernel.

 

 

5. RFC Security in general

 

Remote access via RFC is controlled by authorization object S_RFC on the server side and by authorization object S_ICF on the client side (if this is an ABAP system).

In addition to the normal usage of stored credentials (userid and password) you can use Trusted RFC to get rid of the stored password in some scenarios. Trusted RFC is controlled by authorization object S_RFCACL on the server side.

You can encrypt the communication channel using Secure Network Communication (SNC).

 

Using Transaction SUIM you can search users (report RSUSR002), roles (report RSUSR070), or profiles (report RSUSR020) having full authorizations concerning authorization object S_RFC.

Enter S_RFC for field "Authorization Object" and use the value #* (which represents authorization field value *) for field "RFC_NAME". Dont use wrong values like * or '*' or #**.
Tipp: If you don't get a result this way you should look out for correction notes about RSUSR002, e.g. note 1654478.

 

Here is a collection of useful blogs and presentation about securing RFC:

 

Online help: Creating an Authorization Concept for RFC

http://help.sap.com/saphelp_nw73/helpdata/en/48/8d1a3cae444e6ee10000000a421937/frameset.htm

 

Online help: Authorization Object S_RFC

http://help.sap.com/saphelp_nw70ehp3/helpdata/en/48/8d1bd1ae444e6ee10000000a421937/frameset.htm

 

Online help: Authorization Object S_ICF - Controlling Access to RFC Destinations

http://help.sap.com/saphelp_nw70ehp3/helpdata/en/48/9668140eec3987e10000000a421937/frameset.htm

 

Online help: Authorization Object S_RFCACL

http://help.sap.com/saphelp_nw70ehp3/helpdata/en/48/8d1c6eae444e6ee10000000a421937/frameset.htm

 

Blog: Securing RFC Connections (2004)

http://scn.sap.com/docs/DOC-17089

 

Blog: How to get RFC call traces to build authorizations for S_RFC for free!

http://scn.sap.com/community/security/blog/2010/12/05/how-to-get-rfc-call-traces-to-build-authorizations-for-srfc-for-free

This Blog references to the report ZRFC_STATRECS_SUMMARY which can be used to analyze RFC connections and RFC authorizations.

http://wiki.sdn.sap.com/wiki/display/Snippets/Show+RFC+Workload+Statistic+to+build+authorizations+for+authorization+object+S_RFC

 

Presentation from Teched 2012: SIS264 Securing Remote Access within SAP NetWeaver AS ABAP including SNC and SSL

https://service.sap.com/~sapdownload/002007974700000084412013E/

 

 

6. Message Server security in general

 

In addition to the security vulnerability solved by note 1800603 we like to point your attention to the security configuration options of the message servers.

 

The message server is used for two distinct scenarios:

  • clients logon to application servers via the message server
  • application servers register themselves at the message server 

 

To prevent unwanted clients pretending to the message server to be application servers, you can use parameter rdisp/msserv_internal as described in note 1421005.

 

Note 1421005 Secure configuration of the message server

https://service.sap.com/sap/support/notes/1421005

 

Online help: Monitoring and Administration of the SAP Message Server

http://help.sap.com/saphelp_nw70ehp3/helpdata/en/47/c2e77bb8fd3020e10000000a42189d/frameset.htm

 

Online help: Security Settings for the SAP Message Server

http://help.sap.com/saphelp_nw70ehp3/helpdata/en/47/c56a6938fb2d65e10000000a42189c/frameset.htm

 

 


 

Mit freundlichen Grüßen / Kind regards
Frank Buchholz
Active Global Support - Security Services
mailto:securitycheck@sap.com

 

Security Optimization Service
https://service.sap.com/sos
Security Patch Process FAQ
https://scn.sap.com/community/security/blog/2012/03/27/security-patch-process-faq
Security Notes
https://service.sap.com/securitynotes
System Recommendations for Security Notes
https://service.sap.com/sysrec
Configuration Validation
http://wiki.sdn.sap.com/wiki/display/TechOps/ConfVal_Home

 

Community / Forum / Blogs @ SCN
Security
http://scn.sap.com/community/security
Identity Management
http://scn.sap.com/community/netweaver-idm
Governance, Risk, and Compliance
http://scn.sap.com/community/grc

Introduction

This article describes one particular scenario in which documents can be encrypted by applying a Digital Rights Management (DRM) solution. Documents that are protected by DRM can only be decrypted by their intended audience. For this purpose, the document contains information about which users may access it with which rights, such as read, write, print, etc. Other users are not able to access the document. This makes it safe to distribute the document even via e-mail.

A general introduction to the topic of “Digital Rights Management in SAP Systems” is available on SCN here.

 

Disclaimer

This article does not describe a general solution, but demonstrates one approach on how to integrate DRM into an existing SAP NetWeaver AS ABAP system. For this purpose, one product was selected to perform the DRM related tasks. There are other products on the market. These can be used in a similar fashion, as long as the general procedure to encrypt documents is comparable.

SAP is currently not planning to develop its own DRM product, and SAP also is currently not planning to integrate any specific DRM products into the SAP standard. Customers who want to set up DRM protection have to use non-SAP products.

 

Proof of Concept Implementation Overview

This section describes the specific scenario used in our showcase. First, we describe the use case and general setup, and we list the different protagonists within this scenario and their interaction. The next section shows the detailed configuration of the ABAP system, mainly the required customizing settings and the calling and implementation of the DRM logic. To complete this scenario, the implementation of a Business Add-In (BAdI) is required. The general program logic flow used in this implementation is explained.

This showcase explains one example on how to call the DRM logic. This call needs to be performed at a central place. All documents passing this place will be encrypted. If any other channel for document creation and up- or download is used, the DRM encryption will not take place. Hence, to reach a complete protection in an overall solution, an analysis of the document flow is required: Which channels are used for documents? Only with a consistent concept covering all these channels all relevant documents can be protected.

 

Use Case

The general scenario in which Digital Rights Management protection on data usually is applied looks as follows: In an ABAP system, either a human user or an automatic process access data and make it available for user download. While the human user might instantaneously get access to the downloaded data, the automatic process will usually save the document data for later download. In both cases, the DRM protection shall be applied to the document prior to the download, and even before saving the document in a place where it may be accessed later.

Examples for direct user interaction are reports with information on sales, taxes, or other transactional or master data. Such information can be downloaded for example into spreadsheets for further analysis, or be sent to other persons. Also individual records such as an invoice, a fact sheet about a potential customer, or a material with a component list or construction drawing might be the subject of such downloads. In the most cases, the users start a transaction, select the information they are interested in, and then trigger the download of the information into an MS office, PDF, or any other document format.

Automatic processes could be involved in case mass data is gathered and aggregated into a report. One example could be a legal report in which tax information needs to be listed for auditors in a specific format defined by the tax authorities. Especially in case of time consuming calculations, it makes sense to run a program in the background and provide the result in an appropriate format (such as MS office formats, PDF, or any integrated application-specific format) for download. The access to the download file can be provided by a transaction, or by receiving an e-mail containing a download link.

 

General Setup

Figure 1: Overview of DRM in ABAP provides an overview of the scenario. A human actor or an automatic job access the application logic. In this transaction, data is collected that can be displayed and downloaded. During this download, the DRM protection shall be applied.

The figure shows one block for the existing logic for the document creation. Two additional boxes are shown (highlighted in grey) that are introduced for the DRM scenario. Within the ABAP system, a new block for the DRM logic is introduced. A call to this DRM logic needs to be included into the general logic.

PoC_Diagrams_Overview.png
Figure 1: Overview of DRM in ABAP

 

When a document is created, it is passed from within the application logic to the new ABAP block with the DRM logic. From here, the connection to the DRM tool is established. The document is sent to the DRM tool outside the ABAP system where it is encrypted. The user is not able to prevent this call to the DRM logic.

 

Usage of the Virus Scan Interface

This section provides information on the solution that was opted for in the showcase scenario. As explained in the former section, the document shall be encrypted at a point of time when the data is available, but before handing it to the user (or saving it for later download).

The ABAP system contains a functionality that is able to support this usage: The Virus Scan Interface (VSI). By using the VSI, documents can be sent to virus scan applications that examine the document and return the information whether or not it contains a virus. A description of the VSI is available in the SAP Online help, see here and here.

For the DRM scenario shown in this article, we made use of the VSI. The VSI allows calling own coding, in case a virus scan product is in use that requires specific handling. For this purpose, a Business Add-In (BAdI) is available. Hence, our DRM showcase consists of a configuration part that leads to the calling of a BAdI during the document creation on the one hand and the implementation part on the other hand. The implementation consists of two parts: First, calling the BAdI at the central place of the document flow. Second, implementing the BAdI.

 

Proof of Concept Implementation

Using the Virus Scan Interface (VSI) requires some configuration. The following sections describe this in detail.

In addition, the call to the DRM tool needs to be implemented. This is achieved by introducing the call and by implementing the BAdI that allows specific handling of the VSI. For the former, example coding is shown. For the latter, an example program flow is described that might be used to send a document for encryption and return the encrypted document.

 

Virus Scan Interface Configuration

All configuration tasks for the VSI are performed in customizing. Start transaction SPRO and choose “SAP Reference IMG”. In the customizing tree, the path to the VSI is: SAP Customizing Implementation Guide → SAP NetWeaver → Application Server → System Administration → Virus Scan Interface. All activities mentioned below belong to this node.

PoC_ScreenshotSPRO.png
Figure 2: Customizing activities for VSI

 

First, a Scanner Group is needed. For this purpose, execute the activity “Define Scanner Groups”, choose “New Entries (F5)” and enter a new group – it is important to activate the checkbox “Business Add-In”:

PoC_ScreenshotVSIGroup.png
Figure 3: Example for the attributes of a new Virus Scan Group

 

The second activity “Define Virus Scan Servers” is not needed in this context.

The call to the BAdI later on requires the definition of a virus scan profile. This profile is passed as parameter when instantiating the virus scan functionality. For this purpose, define a new profile in the activity “Define Virus Scan Profile” as in the following example (use a “Z” as prefix in the customer namespace) and activate is by using the respective checkbox:

PoC_ScreenshotVSIProfile.png
Figure 4: Define new virus scan profile

 

To integrate your own virus scan group as a step into a given profile, you need to enter it in the configuration. Mark the entry in question and double-click on “Steps” in the tree on the left. In the detail display, choose “New entries (F5)” (by the respective pushbutton or in the menu via Edit → New entries). Include your new virus scan group by choosing the type “Group” and entering the virus scan group name defined in the respective activity. Save the changes (Ctrl+S or in the menu: Table View → Save).

PoC_ScreenshotVSIProfile_Steps.png
Figure 5: Add new step for a virus scan profile

 

Creating the Business Add-In (BAdI) for VSI

Finally, you need the BAdI for the new virus scanner group. Execute the activity “Implement BAdI for Virus Scanners” and choose “Create (F5)” in the popup.

PoC_ScreenshotVSIBAdI.png
Figure 6: Create BAdI implementation for virus scanner group

 

Enter a filter value containing the name of the virus scanner group, then save and activate:

PoC_ScreenshotVSIBAdIFilter.png
Figure 7: Enter filter value for BAdI implementation

 

For the implementation, switch to the tab “Interface” and double-click on the method name GET_INSTANCE:

PoC_ScreenshotVSIBAdIStarting.png
Figure 8: Starting point for BAdI implementation

 

The method implementation of GET_INSTANCE is quite short and might look like this:

 

method IF_EX_VSCAN_INSTANCE~GET_INSTANCE.
  data: lo_instance type ref to Z_VSI_NEW_GROUP. " example class name
  create object lo_instance.
  eo_instance ?= lo_instance.
endmethod.

 

The coding refers to the own class, in this example: Z_VSI_NEW_GROUP. This class implements the interface IF_VSCAN_INSTANCE. The relevant method is SCAN_BYTES – it is called by using the information returned by the BAdI.

 

Calling the BAdI for VSI

The following code extract shows how the BAdI for the VSI might be called. This code example is not complete. The comments contain information about required actions, such as filling the profile name into the appropriate field and proceeding with the encrypted document after it was returned by the BAdI call.

 

data: lf_profile type vscan_profile
    ,lo_instance type ref to cl_vsi
    ,lf_filename type string
    ,lf_job_id type vscan_job_id
    ,lf_data type xstring
    ,lf_data_encrypted type xstring
    ,lf_scanrc type i
    .

 

" Get profile name into lf_profile (must be filled):
" lf_profile =

 

" Get VSI instance for given profile
call method cl_vsi=>get_instance
  exporting
    if_profile          = lf_profile
  importing
    eo_instance        = lo_instance
  exceptions
    configuration_error = 1
    profile_not_active  = 2
    profile_not_found  = 3
    internal_error      = 4
    others              = 5.
if sy-subrc <> 0.
  " Implement appropriate error handling
  " Error information is available in the system fields
  " See e.g. below:
  " message id sy-msgid type sy-msgty number sy-msgno
  "         with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
endif.

 

" Optional step for VSI: Use file name as Job ID
" If used: Fill lf_filename with file name
call method cl_vsi=>calc_job_id

  exporting
    if_filename      = lf_filename
    if_only_filename = abap_true " optional - without path
                                 " default: file path is kept

  receiving
    ef_job_id        = lf_job_id.

 

" In method get_instance, the settings were evaluated
" --> the following method will cause the calling of desired BAdI

call method lo_instance->if_vscan_instance~scan_bytes
  exporting
    if_job_id          = lf_job_id " optional - default: profile name
    if_data            = lf_data
    if_do_clean        = abap_true " ! Must be set
                                   " -> to get encrypted data back

  importing
    ef_scanrc          = lf_scanrc
    ef_data            = lf_data_encrypted
    " Use following parameter to evaluate errors from BAdI:
    " et_bapiret          =

  exceptions
    not_available      = 1
    configuration_error = 2
    internal_error      = 3
    others              = 4
        .
if sy-subrc <> 0.
  " See above: Implement appropriate error handling
endif.

 

if lf_scanrc = if_vscan_instance=>con_scanrc_clean_ok. " = -1
  " encrypted file is now available in lf_data_encrypted
  " Insert own logic to return encrypted file here

endif.

 

Possible Program Flow for BAdI Implementation

This article shows a possible program flow in Figure 9: Sequence diagram for encryption program flow: During an application, a document is created and encrypted by applying DRM protection. By configuring the VSI as described above, the newly defined BAdI implementation is called.

PoC_Diagrams_Sequence.png
Figure 9: Sequence diagram for encryption program flow

 

Supposing that the DRM tool can be called via a command line tool, the steps for the document encryption look as follows: The document, along with information about the metadata, is passed to the tool. The metadata contains information about the users and the specific rights assigned to the users, as well as the key used for the encryption. The collection of this metadata information is called “template” within this article.

In order to pass the document to the tool, it is first saved to a file system that can be accessed from both the application server and the DRM tool. Use the transaction FILE to define a logical path name for saving this file. By calling the function module FILE_GET_NAME, this path can safely be retrieved by its logical name. The original file name is contained in the importing parameter IF_JOB_ID of the method SCAN_BYTES.

To call the tool from an ABAP system, define an operating system command in transaction SM49. It makes sense to offer the option to pass the file and template name and any further desired options as parameters.

To trigger the execution of an external command from a program, use the function module SXPG_COMMAND_EXECUTE. Note that different application servers might run on different operating systems. In case not all of them fit to the operating system on which the DRM tool is running, a wrapper may be used: By wrapping the call to the external command in an RFC enabled function module, the appropriate application server may be addressed explicitly.

After the encryption was performed by the external command, the document in its location on the file system is encrypted. From here, it needs to be retrieved and then can be passed back to the calling program. We recommend deleting the encrypted file from the file system afterwards.

Refer to the Class Builder (transaction SE24) for the method SCAN_BYTES of interface IF_VSCAN_INSTANCE. The interface documentation contains the link to the method documentation of SCAN_BYTES. All relevant parameters are explained here.

Some detail information on these parameters: The encrypted data is returned in the exporting parameter EF_DATA of method SCAN_BYTES. As the data was modified by the encryption, the exporting parameter EF_SCANRC should be set to -1. This return code indicates to the caller that the data of EF_DATA should be taken over. 

 

Usage of Microsoft Active Directory Rights Management Services

Up to now, this article provided a general description without specifying a certain DRM product. When working on this showcase, we used the product “Microsoft Active Directory Rights Management Services” (Microsoft RMS) as an example. This last section of the article describes how this specific product was used.

The description in this article starts at a point where a Microsoft RMS installation is already present. Hence, the server performing the document decryption at the first access of the document by a user is up and running in the system landscape. Templates have already been uploaded (in this article you can find a description on how to define and upload these templates). These templates contain information on the users who are allowed to access the document, the rights they should have (read, write, print, etc.), as well as the encryption key. The latter was acquired during the system setup.

The direct call of the encryption by the command prompt and the result of the successful encryption could look as follows, with the document c:\usr\sap\hallo.docx and the template c:\usr\sap\RMS_templates\dusers.xml:

PoC_ScreenshotRMSbulk.png
Figure 10: Example for direct call and output of the RMS bulk tool via command prompt

 

Microsoft RMS only supports certain document formats. The tool performs checks for the file ending. For instance, the format “.docx” is allowed, plus additional office formats. The Active Directory Rights Management Services Bulk Protection Tool acts as DRM tool here. The documentation contains a list of supported formats. This tool is available here.

For running this RMS bulk tool, you need operating system commands. From at least one application server, it should be possible to call the RMS bulk tool directly. If this was not possible for all application servers, an RFC enabled function module should be used. The RFC destination for the respective call should then point to an application server that is able to call the RMS bulk tool.

As I already indicated in an earlier blog, SAP is working on a FIPS certification for the crypto kernel of the  Secure Login Library component of our SAP NetWeaver Single Sign-On solution. The certification process is well under way, and soon we will conduct the final tests together with our evaluation lab. If you are looking for more information on FIPS 140-2 and what we are going to certify, check my latest article in the SAP Insider Magazine at  https://scn.sap.com/docs/DOC-34916. Have fun reading!

Having worked for multiple companies with SAP applications, I have consistently found that many security analysts are very careful when maintaining standard transaction authorization objects.  However, when they develop roles for remote connectivity to support interfaces, portal applications, web services, and etc. they provide excessive access.  What do you do if months or even years later you discover that the S_RFC authorization object was implemented with full access to all RFC names?  Can you remediate this access without resulting to rocket science? 

 

You might ask, why not follow standard development processes and gather requirements.  Can you do this without impacting production processes?  Do you have resources that can provide the complete requirements?  In many cases, the appropriate resources are not available to document these requirements after a project is already implemented.  If resources are available, the ability to document the requirements timely becomes an issue.  Even if you implement changes, finding resources available to test the processes can be difficult.  In the end, a timely reduction of risk does not occur.

 

I was recently sharing with another user about a SAP tool for ECC 6 that was provided by Frank Buchholz.  I used this tool to identify and reverse engineer multiple system id’s which were previously provided unrestricted access.  Since this process is more of an art than a science, there are also multiple ways to arrive at the same goal.  I have also been working on enhancements to our Security Audit Log and came across SAP Note 1716731.  The note explains the general process for collecting RFC names through the Security Audit Log.  With the appropriate SM19 settings you can use SM20 to perform analysis once the data is collected.  Depending on the amount of data that you collect, the risk of impacting a production process is greatly reduced.  If you understand the frequency of the processes, you can determine the length of time to analyze.  Once the data is collected, you can export to Microsoft Excel for analysis and summarization.  

 

I believe that by reverse engineering the requirements, the risk can be reduced without negative impact to production business processes.  Whether you use the process documented in SAP Note 1716731 or a utility program that reads the statistics data, you can feel confident that the actual required function groups and functions will be identified.  The true requirements for the authorization object will be complete and after implanting the new authorization object values you will have reduced risk to your environment. 

All ABAP developers are responsible to create secure code. But where can any normal ABAP developer get help in order to assure that the code of his ABAP-based applications does not contain any security issues?

 

Internally, SAP Global IT uses a tool based approach with the new ABAP Test Cockpit (ATC).  While ATC is a generic cockpit for handling findings, SAP Global IT has chosen a 3rd party product, Virtual Forge CodeProfiler, for detecting and prioritizing findings in ABAP code. CodeProfiler is a SAP certified - integration with SAP applications and has been integrated into ATC on a project basis accordingly.

 

It is important to ensure security and compliance of all developed code. Of course, code scanning is not the only method to ensure security. Security standards, compliance as well as data protection guidelines and rules also have to be adhered to. At SAP, this is enforced with a mandatory “Secure programming training” for developers and the secure programming guide. And before any new application goes out for general availability, the validation of the source code is done which contains the automatic source code scan. Subsequently, any found issues are analyzed (e.g. for false positives), prioritized and fixed if necessary, before the application can be published.

We at SAP recommend to our customers to support their developers in their daily effort to develop secure code as much as possible. In order to understand the approach which is enforced at SAP see also the presentation on “ABAP Custom Code Security” that was published in November 2012 by SAP Global IT and the SAP Product Management team.

SAP firefighter installation steps

 

 

Prerequisites:


  • Users must be locked
  • suspend background jobs by using BTCTRNS1 report.
  • Maintain enough free space on Installation directory
  • Download the VIRSANH and VIRSAHR component and put into EPS folder

 

firefighter can be accessed on marketplace via Download --> Support Packages and Patches --->Entry by Application Group -

 

Step1:


Install the firefighter for the first time by using SAINT Tcode.

 

[upgrade the patch level by using SPAM Tcode]

 

1

2

3

 

Now the above two component successfully added into the target system.

 

Step2:Next step is proceed with installation. click on start.

 

4

5

 

First we are going to install the VIRSANH component as per the SAP note recommendation.

Step3:

6

7

 

Check SAP note below for password request:

 

8

 

Note1

 

Step4: Start with background option

 

9

 

Installation phase started.

 

10Step5: Add on was successfully imported. click with finish.

11

 

Step6: Repeat the same steps for the VIRSAHR component.

 

VIRSAHR

 

Reference like password request please read the below SAP note.

 

Note2

 

Step7: We have successfully completed the firefighter installation.

 

 

14

 

We need to apply the patch level to latest Level[N-1 Level]. Please check with market place to find latest SP level for FF.

 

Step8: To increase the patch level by using SPAM Tcode.

 

SPAM

 

16

 

We have completed the component upgrade for the above VIRASANH and VIRSAHR component.

 

17

Introduction

 

With the increased importance of information security and demand for securing systems, SAP started introducing a new feature called Security policies which are similar to Group policies in Active directory.

 

Basic use of these policies is to control set of users with the required options, which means today in SAP all the security related parameters are common for all users. With introduction of security policies we can now provide different restrictions for different users. For example, users in factory need more flexibility because their accounts need to be highly available.

 

So now companies can plan or segregate the users based on the need. The main advantage is companies can enforce strict laws on global level (for all users) and can create flexible security policies for set of users for required parameters like auto unlock accounts.

 

Definitions from SAP

A security policy is a collection of security policy attributes and their values. This procedure replaces the definition of behavior with profile parameters: once a security policy is assigned to a user master record, this determines the desired behavior; profile parameters are only relevant for those user master records for which no security policy has been assigned.

 

Security Policy Attributes (Definition)

A security policy attribute is always an element of a security policy. You can use security policy attributes to define behavior with regard to:

    • Password Rules
    • Password Changes
    • Logon Restrictions

Use

In the application for Maintaining Security Policies (Transaction- SECPOL), you can documentation for an attribute by calling the input help (F4) for the relevant attribute value.

 

How to create /access Security policies:

 

Use transaction code SECPOL –  Switch to change mode and Click on “New entries” to create a new security policy.

S1.JPG

 

 

Once you have created the security policy, select the policy and double click on “Attributes”

 

S2.JPG

Below screen will be displayed and here you need to select the attributes required for the same under “Policy attribute Name” .

S4.JPG

Below are the available attributes for security policies.

 

S5.JPG

The button “Effective” shows the result of the policy in the security policy screen shows as below.

 

S6.JPG

“Superfluous” shows if there are any unnecessary entries (for example the global values and security policy values are same). In the below screen you can see that system shows “CHECK_PASSWORD_BLACKLIST” is unnecessary item as this value is same as system parameter value.

 

S7.JPG

 

How to add this security policy to a User:

Edit the required user in transaction SU01, and enter the required security policy in Logon data tab as shown below.

 

S8.JPG

 

Note: My ECC system’s version is EHP6 FOR SAP ERP 6.0.

 

Useful Links:

 

http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/7f/c52442ad9f5133e10000000a155106/content.htm

Everytime asked yourself what to do in order to use a basic password pop up as authentication mechanism instead of a form based login (which uses the HTML logon page)? This is how your web.xml file has to look like. (In addition, do not forget to use security constraints on all HTTP methods in the web.xml, as also a security role.)

 

...

<login-config>

  <auth-method>BASIC</auth-method>

  <realm-name>Put here the name, which appears as header in the basic password pop up</realm-name>

</login-config>

<security-constraint>

  <display-name>Authenticated users only</display-name>

  <web-resource-collection>

    <web-resource-name>root</web-resource-name>

    <url-pattern>/*</url-pattern>

    <http-method>GET</http-method>

    <http-method>POST</http-method>

    <http-method>TRACE</http-method>

    <http-method>DELETE</http-method>

    <http-method>CONNECT</http-method>

    <http-method>PUT</http-method>

    <http-method>HEAD</http-method>

    <http-method>OPTIONS</http-method>

  </web-resource-collection>

  <auth-constraint>

    <description>all</description>

    <role-name>all</role-name>

  </auth-constraint>

  <user-data-constraint>

    <transport-guarantee>NONE</transport-guarantee>

  </user-data-constraint>

</security-constraint>

<security-role>

  <role-name>all</role-name>

</security-role>

...

 

In addidion, add a security role mapping to your web-j2ee-engine.xml.

 

...

<security-role-map>

  <role-name>all</role-name>

  <server-role-name>all</server-role-name>

</security-role-map>

...

Once in a while you think about deploying a custom Web Application on your AS Java. If this application is using basic password authentication as default, how to use the build in SSO functionality, which reuses your Logon Ticket (aka MYSAPSSO, SSO cookie,...), e.g. generated by your Enterprise Portal application? Here are the steps to be done in NetWeaver Administrator (NWA) therefore.

 

Open NWA and navigate to Authentication and Single Sign On.

1-nwa.png

Search for the web application (aka policy configuration) you want to change.

2-authentication.png

Go to edit mode.

3-edit.png

Change the used template to ticket and save the configuration.

4-save.png

Add the end, make sure to restart the web application.

 

A request, which is pointing to this web application, performs now the login modules shown above, e.g. evaluating an existing ticket, if not existing, prompting for username and password, and at the end creating a ticket for your user.

 

Have you ever wondered because of a new instance of an auth object being pulled in when you just deleted a transaction code from a role?

 

New auth object pulled in role is expected and is also obvious when a transaction code is added to a role, but at first thought it looks weird when you see a new auth object instance pulled in due to removal of a t-code.

 

When you dig it up you realize that this is not because of the t-code you removed but some other one already available in the role which just pulled in because some action of yours on the role. Change document will have your user id as “added by”. Let`s understand the behavior of profile generator to get the clear picture.

 

Whenever you touch menu items of a role (add/remove t-code) and then switch to adjust authorizations (auth tab) the profile generator refers to SU24 data of all the t-codes available in the menu (not only for the one you added/deleted) and searches the exact match of field values in standard or maintained auth objects within role (whether active or inactive) and if found missing then it pulls in a new instance of such auth objects as maintained in profile generator table USOBT_C.

 

Scenarios when a new auth instance will be pulled for a t-code (already available in role) whenever role menu is adjusted (another t-code is added to or deleted from the role)

  • In past while adjusting authorizations if you have changed the status of an object from “standard” to  “changed”  i.e. from standard.JPG tochanged.JPGby altering the default values
  • In past while adjusting authorizations if you have deleted a standard authorization object

 

Reason why it`s always advisable not to delete or change standard authorizations rather make a copy of standard authorization adjust it as per need and deactivate the original standard authorization. 

 

So, coming back to our initial point the auth instance of an object pulled in when you deleted a t-code in role is not because the t-code which was deleted but it`s because of a t-code already available in role for which standard object was tampered. The best practice is to deactivate any new authorizations pulled in if it is not because of the t-code added (or deleted as in this case) by you. This will avoid such occurrence in future.

 

So by default whenever menu items of a role got changed profile generator refers to SU24 data and brings in new authorizations in role if required. If you want to control the default behavior of profile generator you can do it by entering in Expert mode of profile generator

e mode.jpg

This will give you three different ways (maintenance types) to adjust profile

expert-mode.jpg

Option 1: Delete and recreated profile and authorizations

            With this option all the previously maintained authorizations within profile will be deleted and profile generator will fetch fresh SU24 data for all the t-codes available in role menu. This would be a complete profile recreation and all values maintained, changed and authorization objects added manually will be lost and need to be redone if they are needed back.

 

Option 2: Edit old status

            Whenever role menu is adjusted profile generator will refer SU24 data, for some reason if you want profile generator not to refer SU24 data (eventually no adjustment in authorizations automatically) then you need to select this option. Irrespective of the tcode added/deleted in menu this option will keep the same authorizations as available in role the last time it was saved. Last saved (not generated) authorizations can be seen, adjusted for regeneration of profile. No authorization will be pulled in nor deleted from the role.

 

Option 3: Read old status and merge with new data

            Most commonly used and is same as normal change mode (if menu is adjusted) i.e. profile generator will refer to SU24 data and bring in new authorizations in role if needed with no loss of previously maintained authorization. In other words new authorizations will be added on top of old authorizations which can be then adjusted for regeneration of profile. It becomes necessary to opt for this option when you adjust SU24 data for a t-code and want the adjusted values to be pushed in the roles containing this t-code without touching the menu items.

 

 

Hope this gives a clear understanding of Profile Generator`s behavior and helps you to deal with unusual situations during profile generation.

Filter Blog

By author:
By date:
By tag: