• No se han encontrado resultados

Luces y visibilidad

In document MANUAL DE INSTRUCCIONES. Ibiza (página 99-104)

The application-access (.xsaccess) file enables you to specify whether or not to expose package content, which authentication method is used to grant access, and what content is visible.

Example

The Application Access (.xsaccess) File

The following example shows all possible keyword combinations in the SAP HANA XS application-access (.xsaccess) file.

Note

In the form shown below, the .xsaccess file is not a working model; it is used to illustrate all possible options.

{

"exposed" : false,

"authentication" : // null = no auth required, [ { "method": "LogonTicket", }, { "method": "Form", }, { "method" : "Basic" } ], "authorization": [ "sap.xse.test::Execute", "sap.xse.test::Admin" ] "rewrite_rules" : [{ "source" : "...", "target" : "..." }], "mime_mapping" : [ { "extension":"jpg", "mimetype":"image/jpeg" } ], "force_ssl" : true, "enable_etags" : false "prevent_xsrf" : false }

exposed

{ "exposed" : false, }

The exposed keyword enables you define if content in a package (and its subpackages) is to be made available by HTTP to client requests. Values are Boolean true or false. If no value is set for exposed, the default setting (false) applies.

authentication

{ "authentication" : [ { "method": "LogonTicket", }, { "method": "Form", }, { "method" : "Basic", } ], }

The authentication keyword enables you to define the authentication method to use for Browser requests either at the application level or for single packages in an application. SAP HANA Extended Application Services support the following logon authentication mechanisms:

Note

The default setting is basic. You can specify multiple authentication methods in the application-access file. ● Basic authentication

Logon with a recognized database user name and password. ● SAP logon ticket

SAP logon tickets enable single sign-on across SAP boundaries, for example, to set up single sign-on (SSO) between SAP NetWeaver and SAP HANA XS. SAP logon tickets can be also be used as authentication for access to third-party applications.

To configure the trust relationship between the issuer of the SAP logon ticket and SAP HANA, you must specify the path to the SAP logon ticket trust store, which contains the trust chain for the ticket issuer. You can use the SapLogonTicketTrustStore keyword in the xsengine.ini file. Default values are: $SECUDIR/ saplogon.pse or $HOME/.ssl/saplogon.pem.

Note

SAP HANA XS does not issue SAP logon tickets; it only accepts them. Since the tickets usually reside in a cookie, the issuer and SAP HANA XS need to be in the same domain to make sure that your browser sends the SAP logon ticket cookie with each call to SAP HANA XS.

● Form-based authentication

Redirect the logon request to a form to fill in, for example, a Web page.

Form-based authentication requires the libxsauthenticator library, which must not only be available but also be specified in the list of trusted applications in the xsengine application container. The application list is displayed in the SAP HANA studio's Administration Console perspective in the following location:

Administration Configuration tab xsengine.ini application_container application_list . If it is not displayed, ask the SAP HANA administrator to add it.

If you need to troubleshoot problems with form-based logon, you can configure the generation of useful trace information in the XSENGINE section of the database trace component using the following entry:

xsa:sap.hana.xs.formlogon.

If you use the authentication in the .xsaccess file, you must specify the authentication method to apply, for example, basic or SAP logon ticket. If you use the authentication keyword in the application-access file, but do not set an authentication method, your .xsaccess file is a valid JSON file but is not a semantically valid .xsaccess file and will return a parsing validation error . If you do not set the authentication keyword, your application applies the default basic authentication method (user name and password) to enable access to data.

Note

You can disable authentication checks with the null options, as follows: {"authentication" : null}.

authorization

{ "authorization": [ "sap.xse.test::Execute", "sap.xse.test::Admin" ] }

The authorization keyword in the .xsaccess file enables you to specify which authorization level is required for access to a particular application package, for example, execute or admin on the package sap.xse.text.

Note

The authorization levels you can choose from are defined in the .xsprivileges file for the package, for example, "execute" for basic privileges, or "admin" for administrative privileges on the specified package. If you use the authorization keyword in the .xsaccess file, for example, to require “execute” privileges for a specific application package, you must create a .xsprivileges file for the same application package (or a parent package higher up the hierarchy, in which you define the “execute” privilege level declared in the .xsaccess file.

rewrite_rules

{ "rewrite_rules" : [{ "source" : "...", "target" : "..." }] }

The rewrite_rules keyword enables you hide the details of internal URL paths from external users, clients, and search engines. Any rules specified affect the local application where the .xsaccess file resides (and any subpackage, assuming the subpackages do not have their own .xsaccess files); it is not possible to define global rewrite rules. URL rewrite rules are specified as a source-target pair where the source is written in the JavaScript regex syntax and the target is a simple string where references to found groups can be inserted using

$groupnumber.

mime_mapping

{ "mime_mapping" : [ { "extension":"jpg", "mimetype":"image/jpeg" } ] }

The mime_mapping keyword enables you to define how to map certain file suffixes to required MIME types. For example, you can map files with the .jpg file extension to the MIME type image/jpeg.

force_ssl

{

"force_ssl" : false, }

The force_ssl keyword enables you to refuse Browser requests that do not use secure HTTP (SSL/HTTPS) for client connections. If no value is set for exposed, the default setting (false) applies and non-secured connections (HTTP) are allowed.

enable_etags

{

"enable_etags" : true, }

You can allow or prevent the generation of entity tags (etags) for static Web content using the enable_etags keyword. If no value is set, the default setting (true) applies, in which case etags are generated. Etags are used to improve caching performance, for example, so that the same data is not resent from the server if no change has occurred since the last time a request for the same data was made.

prevent_xsrf

{

"prevent_xsrf" : true }

You can use the prevent_xsrf keyword in the .xsaccess file to protect applications from cross-site request- forgery (XSRF) attacks. XSRF attacks attempt to trick a user into clicking a specific hyperlink, which shows a (usually well-known) Web site and performs some actions on the user’s behalf, for example, in a hidden iframe. If the targeted end user is logged in and browsing using an administrator account, the XSRF attack can compromise the entire Web application.

The prevent_xsrf keyword prevents the XSRF attacks by ensuring that checks are performed to establish that a valid security token is available for a given Browser session. The existence of a valid security token determines if an application responds to the client's request to display content; if no valid security token is available, a 403 Forbidden message is displayed. A security token is considered to be valid if it matches the token that SAP HANA XS generates in the back end for the corresponding session.

Note

The default setting is false, which means there is no automatic prevention of XSRF attacks. If no value is assigned to the prevent_xsrf keyword, the default setting (false) applies.

To include the XSRF token in the HTTP headers, you must first fetch the token as part of a GET request, as illustrated in the following example:

xmlHttp.setRequestHeader("X-CSRF-Token", "Fetch");

You can use the fetched XSRF token in subsequent POST requests, as illustrated in the following code example: xmlHttp.setRequestHeader("X-CSRF-Token", xsrf_token);

Related Links

Server-Side JavaScript Security Considerations [page 245]

If you choose to use server-side JavaScript to write your application code, you need to bear in mind the potential for (and risk of) external attacks such as cross-site scripting and forgery, and insufficient authentication.

In document MANUAL DE INSTRUCCIONES. Ibiza (página 99-104)