Please enable JavaScript.

Coggle requires JavaScript to display documents.

Unit 4: Infrastructure and Authentication Security Overview - Coggle…

- - - - SNC on SAProuter
        The connection between the adjacent SAProuters can be protected using SNC. The SAProuters authenticate each other and exchange encrypted messages. Therefore, a secure tunnel for communications is established between components that may not be able to use SNC. A single SAProuter can act as both the initiator and acceptor for an SNC-protected connection.
        To set up SNC-protected connections between two SAProuters, you must establish an SNC environment in both of the SAProuters and configure SNC for the connection in the SAProuter’s route permission table.
        The SAProuter accepts an incoming connection if it finds a corresponding entry in its route permission table. For normal incoming connections where SNC is not used, SAProuter identifies the communication partner using the source host (IP address) and the destination (host and service). For SNC connections coming from an SAProuter, it uses the source SAProuter’s SNC name for identification.
      - SNC for SAP GUI for Windows
        In a standard SAP setup, users enter their SAP user name and password on the SAP GUI logon screen. SAP user names and passwords are transferred through the network without encryption. To secure connections between your front end and your ABAP system, SAP GUI can be used together with an external security product or with SAP NetWeaver Single Sign-On Secure Login Client. Kerberos tokens or certificates can be sent through SAP GUI and Secure Login Client to the SNC interface. The Secure Login Library then encrypts all communication between the front end and the SAP servers, providing a secure SSO from the end user to the SAP NetWeaver AS.
      - Roadmap – Enabling SNC on SAP AS ABAP
        
        Check and deploy the cryptographic library
        
        Configure SNC (SNC, Identity, Profile parameters, credentials) - SNCWIZARD
        
        Manage SNC PSE - STRUST
        
        Establish trust relationship
        
        Check SNC profile parameters - RZ10
        
        Set up access control list entries - SNCO
        
        The SAP Single Sign-On wizard (transaction SNCWIZARD) simplifies the configuration process with the following steps:
        
        Defines the SNC identity. The default value is CN=<system_ID>.
        
        Sets the profile parameters for SNC and SPNego in the default profile.
        
        Maintains Kerberos and X.509 credentials.
        
        Creates an SNC PSE if it does not exist
      - SNC Parameter Configuration
        Instance profile parameter configurations need to be set up properly. For example, to use the SAP Cryptographic Library, the parameters sec/libsapsecu and ssf/ssfapi_lib require the location of the SAPCryptolib. Parameter ssf/name must be set to SAPSECULIB.
        Transaction SNCCONFIG can be used to check the status of these parameter configurations for any ABAP application server.
        Creation of SNC PSE and Credentials
        To use Trust Manager to create and maintain PSE for SAP NetWeaver AS ABAP, the following options are available:
        
        Create a new PSE using Trust Manager on this SAP NetWeaver AS.
        
        Create PSE on a different server, for example, on the other communication partner, SAP NetWeaver AS, and import the PSE using Trust Manager.
        
        The SAP Trust Manager is used to generate and maintain the SNC PSE and Credentials
        You can use the Trust Manager, transaction STRUST, to maintain the SNC PSE in the following ways:
        
        In transaction STRUST, select the SNC PSE node. In the context menu, choose Create. Fill the necessary fields and save the PSE.
        
        To use SNC, you must assign a password to the PSE. To create the credential, choose Assign Password. If you do not assign the password for the PSE, Trust Manager will have problems later
        
        Alternatively, if you want to use an existing PSE that was created from another SAP NetWeaver AS, you can copy SAPSNCS.pse from your SECUDIR to the SECUDIR of the target system. In transaction STRUST, choose PSE → Import.
      - Setup of Access Control List (ACL) Entries
        In addition to identifying the communication partner using the trust relationship, the AS ABAP also checks the ACLs. These lists specify explicitly which other systems are allowed to connect to this system using SNC.
        The ACLs involved in the process are as follows:
        
        System ACL: Enter the SNC name of the remote system and activate the types of communication that are allowed for this system to connect. For example, RFC, CPIC, DIAG, user authentication using certificates, or user authentication using other external authentication mechanisms, such as PAS.
        
        * Extended User ACL:An entry for SAP NetWeaver AS is needed to use WebRFC, for example with PAS. The entry specifies which users from the system can log on using the SNC connection
        To maintain the extended user ACL, use the table maintenance transaction SM30.
      - Roadmap – Enabling SNC on SAP AS Java
        
        Install the SAP Cryptographic Library and licence ticket
        
        Create (import) the SNC PSE
        
        Create credentials
        
        Establish trust relationships
        
        Set SNC profile parameters
        
        Restart Application server Java
        
        Enabling SNC on SAP NetWeaver AS Java involves almost identical steps to those used for SAP NetWeaver AS ABAP. In fact, the same PSE created for AS ABAP can be used for SAP NetWeaver AS Java. The SAP NetWeaver AS Java parameters for SNC are set differently, based on the Java applications
- - - - Certificate management
        Certificate Lifecycle Management manages the renewal of certificates, and eliminates the need to manually administer certificate expiration. Scheduled background jobs identify expiring certificates and automatically renews them for server-side certificates. Central roll-out of trusted root certificates to the landscape is also supported, along with options to integrate with existing enterprise PKI’s.
        
        Cloud and Cross-Domain Support
        For those who are looking to extend their Single Sign-On solution into the cloud or cover cross-company scenarios, single sign-on and identity federation based on the Security Assertion Markup Language (short SAML) provides a sound solution. SAML is an internet standard that provides a highly flexible Single Sign-On technology that is especially well suited for cross-domain environments
        The benefits of SAML 2.0 are as follows:
        
        Single Sign-On: SAML provides a standard for cross-domain SSO. Other methods also exist for enabling cross- domain SSO, but they require proprietary solutions to pass authentication information across domains. SAML 2.0 supports identity provider-initiated SSO, like in SAML 1.x. SAML 2.0 also supports service provider-initiated SSO.
        
        Single Log-Out (SLO)
        SLO enables users to close all their sessions in a SAML landscape simultaneously, even across domains. SLO not only saves system resources that would otherwise remain reserved until the sessions time out, but it also mitigates the risk of the hijacking of unattended sessions.
        Identity Federation
        Identity federation provides the means to share identity information between partners. To share information about a user, partners must be able to identify the user, even though they may use different identifiers for the same user.
        The main components of a SAML 2.0 landscape are as follows:
        Service provider: The service provider is a system entity that provides a set of web applications for common session management, identity management, and trust management. The service providers outsource the job of authenticating the user to the identity provider.
        Identity provider: The identity provider is a system entity that manages identity information for principals and provides authentication services to other trusted service providers.
        Users authenticate to the IdP to retrieve a SAML assertion which is accepted as proof of identity by browser-based applications on desktop and mobile devices; for example SAP Fiori
        applications. The SAML assertion enables single sign-on during the lifetime of the browser session. The assertion definition is flexible and enables easy mapping of attributes between systems. The identity provider maintains the list of service providers where the user is logged in and passes on logout requests to those service providers. The client that is trying to access the resource must be HTTP-compliant.
        SAP Identity Provider supports two-factor and risk-based authentication against different user data stores (LDAP, ABAP, and so on).
        
        Front Channel Single Sign-On based on (SAML) 2.0
        The figure illustrates service-provider-initiated SSO with front-channel communication.
        The following steps explain the process flow of the front-channel SSO:
        
        A user attempts to access a resource protected by SAML 2.0.
        
        The service provider redirects the user to an identity provider for authentication.
        
        The identity provider queries the user for authentication credentials
        
        The user or user agent presents the requested credentials.
        
        The identity provider returns the user to the service providers with an authentication response
        
        The service provider presents the requested resource to the user.
        
        Back channel single sign-on based on SAML 2.0 functions similarly, but the service provider and identity provider exchange directly exchange authentication credentials via a SOAP channel.
        The process flow utilizing back-channel SMAL 2.0 would include the following steps
        
        A user attempts to access a resource protected by SAML 2.0.
        
        The service provider redirects the user to an identity provider and includes a SAML artifact referring to the authentication request.
        
        The identity provider gets the authentication request from the service provider over a SOAP channel.
        
        The identity provider queries the user for authentication credentials.
        
        The user or user agent presents the requested credentials.
        
        The identity provider returns the user to the service providers with a SAML artefact referring to the authentication response.
        
        The service provider gets the authentication response from the identity provider over a SOAP channel.
        
        The service provider presents the requested resource to the user.
        
        In addition to single sign-on, SMAL 2.0 supports Single Log-Out (SLO). Single Log-Out (SLO) enables users to close all their sessions in a SAML landscape cleanly, even across domains. Not only does this save system resources that would otherwise remain reserved until the sessions time out, but it also mitigates the risk of the hijacking of unattended sessions.
        
        The following steps provide an example of the process flow for SLO with SAML 2.0:
        
        The user initiates a logout request at a service provider
        
        the service provider forwards this request to an identity provider.
        
        After the identity provider validates the request, it sends new logout requests to all other service providers with which the user has a security session that the identity provider is aware of.
        
        The service providers validate the request, destroy any session information for the user, and send a logout response to the identity provider.
        
        The identity provider destroys the user’s sessions and sends a response to the original service provider.
        
        The original service provider informs the user that he or she has been logged out.
        
        Identity Federation
        SAML 2.0 also supports Identity Federation. Identity federation provides the means to share identity information between partners.
        SAML describes the following types of federation:
        Out-of-band account linking
        The identities of a user in system A and system B are identified and agreed upon ahead of time between the administrators of the two systems. This kind of agreement is also supported by SAML 1.x. The administrator of the identity provider and the service provider agree how the name ID used for the user in the identity provider maps to the user in the service provider. Use this kind of federation to support most scenarios where you need to map user identities across domains.
        Transient pseudonym identifiers
        Federation with transient name IDs creates a federation with a temporary user in the service provider and a permanent user in the identity provider. This federation exists only as long as the security session with the service provider exists. The service provider does not persist data about the visiting user. User attributes and access rights are generated based on rules applied to attributes sent in SAML messages Use this kind of federation when the service provider does not need to record information about users or do not need local user accounts.
        Persistent pseudonym identifiers
        Federation with persistent name IDs establishes a permanent relationship between a user on an identity provider and a user on a service provider or users on an affiliation of service providers. The persistent name ID is used by an identity provider and a service provider as a common name for a user. If this name ID for a user is the same for multiple service providers, the service providers are said to be affiliated or to belong to an affiliation group.
        Use this kind of federation to link accounts out-of-band, but without using identifiers that can be traced back to a specific user. This increases the security of your systems by preventing eavesdroppers from determining identities on the basis of name ID formats that pass logon IDs or e-mail addresses. It requires you to establish the pseudonym on both providers ahead of time.