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

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
9 Beiträge • Seite 1 von 1
9 Beiträge Seite 1 von 1

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

Beitrag von sapdepp (Specialist / 218 / 37 / 2 ) »
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

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


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

Beitrag von Tron (Top Expert / 1327 / 35 / 332 ) »
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.
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.

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

Beitrag von sapdepp (Specialist / 218 / 37 / 2 ) »
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/ui ... 0041240071

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

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

Beitrag von Dele (Specialist / 307 / 4 / 47 ) »
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.

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

Beitrag von sapdepp (Specialist / 218 / 37 / 2 ) »
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

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

Beitrag von Tron (Top Expert / 1327 / 35 / 332 ) »
.. 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 http://abapforum.com/forum/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.

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

Beitrag von sapdepp (Specialist / 218 / 37 / 2 ) »
... 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

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

Beitrag von Tron (Top Expert / 1327 / 35 / 332 ) »
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

Folgende Benutzer bedankten sich beim Autor Tron für den Beitrag:
sapdepp

<:: 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.

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

Beitrag von sapdepp (Specialist / 218 / 37 / 2 ) »
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

Seite 1 von 1

Vergleichbare Themen

0
Antw.
910
Views
Single Sign-on
von anam.jabrane » 19.04.2014 10:44 • Verfasst in ABAP® für Anfänger
3
Antw.
3339
Views
BSP und Single Sign On
von Meex » 19.08.2005 07:51 • Verfasst in Web-Dynpro, BSP + BHTML
5
Antw.
4687
Views
PDF fehlerhaft nach Übergabe an REST-API von Adobe-Sign
von P4dd3y » 06.05.2021 16:01 • Verfasst in SAP Cloud Platform
1
Antw.
3048
Views
Singel Sign On mit Kerberos OHNE Secure Login Client
von BasisGuy » 27.04.2018 15:06 • Verfasst in SAP - Allgemeines
0
Antw.
2815
Views
Berechtigungsprüfung PNP
von ginotico » 07.05.2008 09:30 • Verfasst in Human Resources

Über diesen Beitrag


Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Daten an Tabelle binden
vor 21 Stunden von Bright4.5 1 / 484
aRFC im OO-Kontext
vor 4 Wochen von ralf.wenzel 1 / 2128
Hilfe bei SWEC/SWE2
letzen Monat von retsch 1 / 8723