ACCESS_CONTROL

The ACCESS_CONTROL element specifies access from a list of IP allowed to access applications or services, GIP StarterApp, and Prometheus metrics endpoint.

Syntax

<ACCESS_CONTROL> 
   [<ALLOW_FROM>...</ALLOW_FROM>][...]
</ACCESS_CONTROL>

Child elements

Usage

You use this element to specify which users have access to applications or services, and to control access to these three areas:

By default, an application or a service is not accessible by anyone; it must be explicitly configured with ALLOW_FROM elements.
<ACCESS_CONTROL> 
  <ALLOW_FROM>127.0.0.1</ALLOW_FROM>
  <ALLOW_FROM>10.</ALLOW_FROM>
  <ALLOW_FROM>192.168.</ALLOW_FROM>
  <ALLOW_FROM>fdbd:2768:c176:1::323a</ALLOW_FROM> 
</ACCESS_CONTROL>
In this example, an application or a service is reachable from the localhost (127.0.0.1), and all IP addresses that begin with "192.168." or "10.", or the IPv6 address "fdbd:2768:c176:1::323a".
Important:

Depending on the network configuration, it is not always possible to get the actual client IP address. For example, if there is a proxy server between the client and the server, the client IP address seen by the GAS may be the address from the proxy server.

For standalone dispatcher, no access control is enforced. For isapidispatch and fastcgidispatch dispatchers, the access decision sequence is as follows:

  • If an ACCESS_CONTROL tag exists, GAS checks the client IP against the ALLOW_FROM entries.
  • If the client IP matches an ALLOW_FROM entry, GAS grants access; otherwise (no match), GAS returns HTTP 403 Forbidden.
  • The ACCESS_CONTROL element recognizes special keywords supplied by resources (for example: res.access.control, res.gip.access.control) in the as.xcf that define access:
    • ALL — permits access from any IP address.
    • NOBODY — disables access entirely (grants access to no IP).
  • If no ACCESS_CONTROL tag exists, access is allowed.

Example configuring access control for demo applications

Access to the default deployment of the demo application is defined by the resource res.access.control, which is set to the value NOBODY to prevent unauthorized execution.
Note:

Access control rules are ignored by the standalone dispatcher (httpdispatch).

To allow access from the localhost, in the GAS (default $FGLASDIR/etc/as.xcf) configuration file you need to change the application element for demo from:

<!--Sample application for GWC-->
<APPLICATION Id="demo" Parent="defaultwa">
  <EXECUTION>
    <ENVIRONMENT_VARIABLE Id="FGLPROFILE" Concat="APPEND">$(res.path.fgldir.demo.services)/fglprofile</ENVIRONMENT_VARIABLE>
    <!--ENVIRONMENT_VARIABLE Id="FGLWSDEBUG">3</ENVIRONMENT_VARIABLE-->
    <PATH>$(res.path.fgldir.demo)</PATH>
    <MODULE>demo.42m</MODULE>
    <ACCESS_CONTROL>
      <ALLOW_FROM>$(res.access.control)</ALLOW_FROM>
    </ACCESS_CONTROL>
  </EXECUTION>
</APPLICATION>
To: 
<!--Sample application for GWC-->
<APPLICATION Id="demo" Parent="defaultwa">
  <EXECUTION>
    <ENVIRONMENT_VARIABLE Id="FGLPROFILE" Concat="APPEND">$(res.path.fgldir.demo.services)/fglprofile</ENVIRONMENT_VARIABLE>
    <!--ENVIRONMENT_VARIABLE Id="FGLWSDEBUG">3</ENVIRONMENT_VARIABLE-->
    <PATH>$(res.path.fgldir.demo)</PATH>
    <MODULE>demo.42m</MODULE>
    <ACCESS_CONTROL>
      <ALLOW_FROM>127.0.0.1</ALLOW_FROM>
    </ACCESS_CONTROL>
  </EXECUTION>
</APPLICATION>

Example configuring access control for Genero Identity Provider

Access to the Genero Identity Provider applications is specified by the resource res.gip.access.control. This is set with the value NOBODY by default.

To allow users to have access to the StarterApp for its initial launch, you need to change the GAS (default $FGLASDIR/etc/as.xcf) configuration file for res.gip.access.control to ALL:
<RESOURCE Id="res.gip.access.control" Source="INTERNAL">ALL</RESOURCE>

After setting up the GIP, remember to reset the resource back to NOBODY to restrict access and prevent users from running the StarterApp. In production, ensure that the resource is also set to NOBODY for the same reason.

For more details about methods to configure access for the StarterApp, refer to the Configure the GIP page in the Single Sign-On User Guide.

Example configuring access control for Prometheus metrics

When used within a PROMETHEUS element, it controls which IP addresses are allowed to access the Prometheus metrics endpoint.

Example configuration:
<PROMETHEUS Enabled="$(res.prometheus.enabled)">
  <COLLECTOR Address="$(res.prometheus.address)" Port="$(res.prometheus.port)" />
  <HISTOGRAM_BUCKETS Name="fourjs_gas_request_duration_seconds">$(res.prometheus.rq_duration.buckets)</HISTOGRAM_BUCKETS>
  <ACCESS_CONTROL>
    <ALLOW_FROM>127.0.0.1</ALLOW_FROM>
    <ALLOW_FROM>192.168.</ALLOW_FROM>
  </ACCESS_CONTROL>
</PROMETHEUS>

In this example, the Prometheus metrics endpoint is accessible only from localhost (127.0.0.1) and from IP addresses that begin with "192.168.".

Warning:

When using ACCESS_CONTROL with Prometheus, ensure you properly restrict access to your metrics endpoint to prevent unauthorized access to sensitive monitoring data. For standalone dispatcher, no access control is enforced.

The as.xcf file includes a default ACCESS_CONTROL under PROMETHEUS but contains no ALLOW_FROM entries — so access is blocked by default. To allow unrestricted access to Prometheus, remove the ACCESS_CONTROL tag from under PROMETHEUS. If an ACCESS_CONTROL tag is present under PROMETHEUS, the isapidispatch and fastcgidispatch dispatchers check for ALLOW_FROM entries and grant access only when a request matches one.

Parent elements

This element is a child of one of the following elements: