Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign On


Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV

Moderatoren: Jan, Steff

Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign On

Beitragvon sapdepp » 15.12.2017, 15:57

Hallo,

mal fix das Problem grob beschrieben:

Ein SAP-Nutzer SCHMIDT zündet im SAP-System im Dialog einen Button. Dem Button liegt Funktionscode zugrunde, u. a. der Aufruf einer parametrierten URL mit der Cl_Gui_Frontend_Services=>Execute-Methode. Die URL (HTTPS) zweigt in ein anderes SAP-System per Single Sign On mit einem vorgegebenen Nutzer SSOUSER. In dem System sind Gateway-Services hinterlegt, Transaktion SICF. In den Services steht der Nutzer SSOUSER als fester RFC-Nutzer mit vorgegebenem Passwort fest drin. Dieser SSOUSER wählt sich seinerseits mit diesen Services zurück ins KC5 und startet über RFC diverse Funktionsbausteine zur Anzeige von Daten innerhalb einer SAPUI5-Ansicht. Hier liegt der Hund begraben. Der SSOUSER hat natürlich weitreichendere Rechte als der Nutzer, der den Button geklickt hat. Ich möchte aber ein Authority Check zünden für den Nutzer, der den Button einst geklickt hat. Der ist aber zum Zeitpunkt des RFC nicht mehr im Hauptspeicher, sondern nur noch der SSOUSER. Und auf dem Hinweg ins Gateway-System habe ich noch nicht die Daten zur Verfügung, für die ich eine Berechtigungsprüfung machen müsste, sonst wär es ja einfach. Die erhalte ich erst auf dem Rückweg. Es gibt ein paar unschöne Tricks, mit denen ich mir den wahren SAP-Nutzer ablegen kann, um diesen zu prüfen. Aber gibt es was Elegantes? Muss ich im Gateway-System in der SICF was konfigurieren? Ich will, dass der echte, ausführende SAP-Nutzer zur Laufzeit der ganzen RFC-Gedöns bekannt bleibt. Bitte kein Export to Memory o. s. ä. Der FB SU_RAUTH_CHECK_FOR_USER nützt uns übrigens an der Stelle nix ... Die Ganze Sache ist im UI5-Umfeld angesiedelt, Stichworte GET_ENTITY, model.js usw. Ich hole hier mal nicht weiter aus. ;-)

Vielen Dank und viele Grüße

sapdepp
sapdepp
Specialist
 
Beiträge: 147
Registriert: 17.12.2008, 16:13
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign

Beitragvon Tron » 17.12.2017, 11:04

Moin.
mal fix eine mögliche Lösung grob beschrieben:

unter den gegebenen Umständen würde ich den Usernamen als URL-Parameter mit übertragen.
e.g.
http://Sapserver.com/service?uname=SCHMIDT
oder sicherer mit BASE64
http://Sapserver.com/service?uname=U0NITUlEVA==


Der SICF-Service kann diesen Namen auswerten, (wenn man es programmiert).
Für die Berechtigungsprüfung einen RFC-Baustein im Ursprungssystem anlegen,
oder
SUSR_USER_AUTH_FOR_OBJ_GET Remote verwenden,
der dann genutzt wird, die Prüfung für "SCHMIDT" durchzuführen.
eg.
Code: Alles auswählen
FUNCTION z_rfc_auth_check.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     VALUE(I_USER) TYPE  XUBNAME
*"  EXPORTING
*"     VALUE(O_RC) TYPE  SYST-SUBRC
*"----------------------------------------------------------------------

* AB ECC6 !!
*AUTHORITY-CHECK OBJECT 'S_TCODE' FOR USER i_user
*         ID 'TCD' FIELD 'MM03'.

** Check authorization for user
*AUTHORITY-CHECK OBJECT 'Z_TR_SALES'
*FOR USER i_user
*ID 'VKORG' FIELD lv_vkorg
*ID 'VTWEG' FIELD lv_vtweg
*ID 'SPART' FIELD lv_spart
*ID 'ACTVT' FIELD '09'.


* AB 4.7
  DATA: BEGIN OF values OCCURS 10.
          INCLUDE STRUCTURE usvalues.
  DATA: END OF values.


  CALL FUNCTION 'SUSR_USER_AUTH_FOR_OBJ_GET'
    EXPORTING
      user_name      = i_user
      sel_object     = 'S_TCODE'
    TABLES
      values         = values
    EXCEPTIONS
      user_not_exist = 1
      not_authorized = 2
      internal_error = 3
      OTHERS         = 4.


  IF values[] IS INITIAL.
    o_rc = 1.
  ELSE.
    o_rc = 0.
  ENDIF.

ENDFUNCTION.

Anderes Beispiel:
Code: Alles auswählen
FUNCTION z_rfc_auth_check.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     VALUE(I_USER) TYPE  XUBNAME
*"     VALUE(I_TCODE) TYPE  SYST-TCODE DEFAULT 'MM03'
*"  EXPORTING
*"     VALUE(O_RC) TYPE  SYST-SUBRC
*"----------------------------------------------------------------------

  AUTHORITY-CHECK OBJECT 'S_TCODE' FOR USER i_user
           ID 'TCD' FIELD I_TCODE.

  o_rc = sy-subrc.


ENDFUNCTION.

gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Tron
Expert
 
Beiträge: 894
Registriert: 04.08.2007, 21:08
Wohnort: Hamburg
Dank erhalten: 161 mal
Ich bin: Entwickler/in

Re: Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign

Beitragvon sapdepp » 18.12.2017, 09:31

Hallo, Tron,

vielen Dank für die Antwort.

Der SICF-Service kann diesen Namen auswerten, (wenn man es programmiert).


Das hieße, dass SAP den Service umbauen müsste, damit ich im Link den Nutzernamen des aufrufenden Backend-Systems übergeben kann? Zurzeit sieht der Link in Klarschrift nämlich so aus:
https://sap04.kc.skc.de:44300/sap/bc/ui5_ui5/sap/zmemr_findings/index.html?sap-ui-language=DE&PatientId=INST_PAT_ID_0100010041240071

Der Server sap04 ist der Server, auf dem der SICF läuft (Gateway-System). Wenn ich dort irgendwo in der URL sy-uname unterbringen könnte, dass der aufrufende Nutzername im Gateway-System noch bekannt ist, wäre das mehr als die halbe Miete. Anschließend könnte ich den RFC-Authority-Check mit dem echten Nutzer durchführen ...

VG
GA
sapdepp
Specialist
 
Beiträge: 147
Registriert: 17.12.2008, 16:13
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign

Beitragvon Dele » 18.12.2017, 12:18

Nur mal so als Idee: Stichwort "Trusted Systems" - Transaktion SMT1
Anstatt per HTTP in das andere SAP-System zu gehen, könnte man auch per RFC in das andere System gelangen. Wichtig dabei ist, dass man eine RFC-Destination verwendet, die als "Trusted" definiert ist. Dann gelangt man nämlich mit dem gleichen Benutzer in das andere SAP-System. Der Benutzer muss dort natürlich auch (entsprechend Single-Sign-On) mit entsprechenden Rechten und gleicher User-ID definiert sein. Voraussetzung dafür ist, dass die beiden SAP-Systeme sich "vertrauen". Das kann man mit der Transaktion SMT1 einrichten. (Haben wir mit allen unseren SAP-Systemen eingerichtet und nutzen das auch ganz massiv seit Jahren und funktioniert super)

Im Zielsystem wird ein selbst entwickelter RFC-fähiger Funktionsbaustein aufgerufen. In diesem Funktionsbaustein man dann die gewünschten Berechtigungsprüfungen machen. Wenn alles OK ist, dann wird die parametrierte URL, die man dem Funktionsbaustein übergeben hat, aufgerufen.
Sollte dieser Weg so nicht funktionieren, dann könnte der Funktionsbaustein zumindest die erforderlichen Berechtigungsprüfungen machen und OK oder nicht-OK zurückliefern und dementsprechend kann man dann reagieren.
Dele
Specialist
 
Beiträge: 282
Registriert: 06.05.2005, 11:07
Dank erhalten: 41 mal

Re: Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign

Beitragvon sapdepp » 18.12.2017, 14:07

Trusted RFC verwenden wir auch, wenn sich (wenige Nutzer) direkt übers iPad im System anmelden. Aber die reine UI5-Ansicht am Frontend im Browser (Chrome) starten dann wirklich über 2000 Nutzer per Mausklick aus NWP1 oder N1PATORG. Die können/wollen wir nicht noch mal alle per Hand im Gateway-System in der SU01 anlegen, sondern alle dynamisch mit einem einzigen SSOUSER und einem einzigen Kennwort erschlagen. Und nein, wir haben keine zentrale Benutzerverwaltung, falls Fragen kommen. Demzufolge wäre es für uns schon wichtig, in der URL (versteckt) den SAP-Benutzernamen ans Gateway zu übertragen ...

VG
sapdepp
sapdepp
Specialist
 
Beiträge: 147
Registriert: 17.12.2008, 16:13
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign

Beitragvon Tron » 18.12.2017, 14:27

.. nun nach meiner Idee sähe der Link z.B. so aus:
https://sap04.kc.skc.de:44300/sap/bc/ui ... 0041240071&uname=U0NITUlEVA==
Im Service wird dann aus dem Request-Object der Url-Parameter "Uname" extrahiert und Base64 dekodiert.
Dein Link ist ja im SAP-Namensraum, Du hast allerdings die Möglichkeit der Anlage eines ALIAS auf den Service im SICF Baum .
siehe auch mein PDF viewtopic.php?f=1&t=17609
gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Tron
Expert
 
Beiträge: 894
Registriert: 04.08.2007, 21:08
Wohnort: Hamburg
Dank erhalten: 161 mal
Ich bin: Entwickler/in

Re: Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign

Beitragvon sapdepp » 18.12.2017, 16:36

... aha, und ich dachte, der String U0NITUlEVA wäre ein willkürlich in die Tastatur gehämmerter Wert, um zu zeigen, dass der sy-uname verschlüsselt übertragen wird. :) Ich habe noch nichts von Base64 oder gar U0NITUlEVA gehört. Deswegen ist es für mich auch schwer nachzuvollziehen, wo und wie der SICF-Service von sich aus den sy-uname wieder decodiert.

Vielen Dank für die Doku. Das ist interessant. Ich habe noch nie eigene SICF-Services angelegt etc. Liegt sicher daran, dass ich mich erst seit paar Tagen intensiver mit der Sache beschäftigen muss. :D Wenn ich also ein Alias auf den bestehenden Service ZMEMR_FINDINGS als Top-Level-Knoten anlege, wird dessen Handler-Liste gezogen und die dortige Methoden gezündet, u. a. die HANDLER_REQUEST, mit dem Charme, dass der aufrufende Nutzer mit übergeben wird, während der globale Service.Nutzer SSOUSER erhalten bleibt? Leider hat dieser Service keine Handler-Liste. :o Ich könnte ja eine Methode eintragen, die wir in einem ähnlichen Service verwenden und die sich da IF_HTTP_EXTENSION~HANDLE_REQUEST nennt ... Oder ich lege eine eigene an. Irgendwo muss ja die Decodierung stattfinden anhand des Parameters &uname=U0NITUlEVA==.

VG
sapdepp
sapdepp
Specialist
 
Beiträge: 147
Registriert: 17.12.2008, 16:13
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign

Beitragvon Tron » 20.12.2017, 16:33

So.
Ich habe noch nichts von Base64 oder gar U0NITUlEVA gehört

https://www.base64decode.org/
Base64 ist Umsetzung von Zeichensätzen und dient der Übertragungssicherheit (besonders bei Steuerzeichen).
Der Handler ( Weiterleitung )
Code: Alles auswählen
METHOD if_http_extension~handle_request.

****************************************
* copy of CL_HTTP_EXT_BASE
****************************************
* Example with output
*data output_str type string.
*
*
** allow other extensions to do something
*  if_http_extension~flow_rc = if_http_extension=>co_flow_ok_others_opt.
*
*
** create some response data
*  server->response->set_header_field(
*    name  = 'Content-Type'                                  "#EC NOTEXT
*    value = 'text/html' ).
*  server->response->set_header_field(
*    name  = 'Expires'                                       "#EC NOTEXT
*    value = '0' ).
*
*
*output_str = 'Hello caller1'.
*
*
*  server->response->set_cdata( data = output_str ).


  DATA l_b64value TYPE string.
  DATA l_b64url TYPE string.
  DATA l_value TYPE string.
  DATA l_newurl TYPE string.
  DATA l_rc TYPE syst-subrc.
  DATA msg_text(80).

* allow other extensions to do something
  if_http_extension~flow_rc = if_http_extension=>co_flow_ok_others_opt.

  l_b64value = server->request->get_form_field( name = 'UNAME' ).
  IF l_b64value IS INITIAL.
    server->response->set_status( code = 403 reason = 'illegal call' ).
    EXIT.
  ENDIF.

  l_b64url = server->request->get_form_field( name = 'UX' ).
  IF l_b64url IS INITIAL.
    server->response->set_status( code = 404 reason = 'illegal call' ).
    EXIT.
  ENDIF.

* Decode Base64 String e.g.https://www.base64decode.org/
  l_value = cl_http_utility=>decode_base64( l_b64value ).
  l_newurl = cl_http_utility=>decode_base64( l_b64url ).

* Check authority
  CALL FUNCTION 'Y_RFC_AUTH_CHECK' DESTINATION 'NONE'
    EXPORTING
      i_user                = l_value
      i_tcode               = 'MM03'
    IMPORTING
      o_rc                  = l_rc
    EXCEPTIONS
      communication_failure = 1 MESSAGE msg_text
      system_failure        = 2 MESSAGE msg_text.

  IF NOT l_rc IS INITIAL.
    server->response->set_status( code = 404 reason = 'illegal call' ).
    EXIT.
  ENDIF.

  server->response->redirect( url = l_newurl ).
ENDMETHOD.


Das Prinzip ist folgendes:
1.) Man legt den Handler mit SE24 an (kopie von CL_HTTP_EXT_BASE) und richtet einen Service ein (SICF).
2.) Anstatt den ursprünglichen Service direkt aufzurufen , wird der Handler aufgerufen und das eigentliche Ziel und der zu prüfende User in der URL übergeben.
3.) Ist die Prüfung positiv verlaufen, wird an den eigentlichen Service weitergeleitet, ansonsten abgewiesen.

Die Urspügliche URL wird dadurch wie folgt geändert aufgebaut:
http://<Neuer Service>?ux=Base64(URL)&uname=Base64(Sy-UNAME)

gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.

Für diese Nachricht hat Tron einen Dank bekommen :
sapdepp
Tron
Expert
 
Beiträge: 894
Registriert: 04.08.2007, 21:08
Wohnort: Hamburg
Dank erhalten: 161 mal
Ich bin: Entwickler/in

Re: Berechtigungsprüfung Dialog- vs. RFC-User im Single Sign

Beitragvon sapdepp » 05.01.2018, 15:14

Vielen Dank für die Antwort. Ich werde das ausprobieren. Wir hatten noch eine andere Idee, die wir momentan umsetzen bzw. umsetzen lassen. Dazu muss allerdings auch einiges an der UI5-App angepasst werden.

LG
sapdepp
sapdepp
Specialist
 
Beiträge: 147
Registriert: 17.12.2008, 16:13
Dank erhalten: 0 mal
Ich bin: Entwickler/in


Zurück zu ABAP® Core

  Aktuelle Beiträge   
Dokumente aus Dokumentenvewaltung als Mailanhang versenden
vor 53 Minuten von zzcpak 3 Antw.
gruppieren von internen Tabellen
vor 2 Stunden von DeathAndPain 2 Antw.
QM Probenanlage, User-Exit gesucht
Gestern von SAP_ENTWICKLER 0 Antw.
Felder in SAP Script
Gestern von a-dead-trousers 1 Antw.
"Lagerort Kunde" aus IDOC im Lieferplan speichern
Gestern von Alexander D. 0 Antw.

  Ähnliche Beiträge beta
Performanceproblem mit SELECT SINGLE
11.05.2006, 07:11 von Andreas G 5 Antw.
ALV Grid in Modaler Dialog Box
08.07.2005, 14:48 von black_adept 1 Antw.
Dialog-RFC kommt nicht in den Vordergrund
11.04.2005, 12:43 von xanatos 0 Antw.
Weiterschalten im Dialog funktioniert nicht
09.01.2006, 15:44 von Gast 0 Antw.
PROCESS ON VALUE-REQUEST & dialog neu aufbauen
29.03.2006, 10:16 von ewx 5 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder

Feedback ...?

Was können wir verbessern? Hinterlasse deine Kontaktdaten, wenn du eine direkte Antwort möchtest.

... Absenden!