SG Anonymous authentication

Hi Team,

I have trouble setting up Anonymous authentication for Kibana, I use proxy auth (SAML) to allow users to access kibana. When I login with test user username is not set to sg_anonymous, uses the username from x-proxy-user. May I know whether Anonymous authentication works with only basic auth.

I would like a flow as if user is not present in roles_mapping, sg_ananymous should be triggered.
For any further information please do let me know.

Best,
Yash

Can you please post your sg_config.yml and elasticsearch.yml?

@cstaley Thanks for your response, I have attached the required below.

sg_config.yml

_sg_meta:
  type: "config"
  config_version: 2

sg_config:
  dynamic:
    
     #filtered_alias_mode: warn
      do_not_fail_on_forbidden: true
      kibana:
        multitenancy_enabled: true
        server_username: 'kibana'
        index: '.kibana'
      http:
        anonymous_auth_enabled: true
        xff:
          enabled: true
          #internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern
          internalProxies: '.*' # trust all internal proxies, regex pattern
          remoteIpHeader:  'x-forwarded-for'
      authc:
        basic_internal_auth_domain:
          description: "Authenticate via HTTP Basic against internal users database"
          http_enabled: true
          transport_enabled: true
          order: 1
          http_authenticator:
            type: basic
            challenge: true
          authentication_backend:
            type: intern
        proxy_auth_domain:
          description: "Authenticate via proxy"
          http_enabled: true
          transport_enabled: true
          order: 0
          http_authenticator:
            type: proxy
            challenge: false
            config:
              user_header: "x-proxy-user"
              roles_header: "x-proxy-roles"
          authentication_backend:
            type: noop

elasticsearch.yml


# ---------------------------------- Searchguard -------------------------------
searchguard.config_index_name: searchguard7
searchguard.ssl.transport.enabled: true
searchguard.ssl.transport.keystore_filepath: 
searchguard.ssl.transport.keystore_password: 
searchguard.ssl.transport.truststore_filepath: 
searchguard.ssl.transport.truststore_password: 
searchguard.ssl.transport.enforce_hostname_verification: false
#searchguard.ssl.transport.http.enforce_clientauth: optional
searchguard.ssl.http.clientauth_mode: OPTIONAL
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_filepath: 
searchguard.ssl.http.keystore_password: 
searchguard.ssl.http.truststore_filepath: 
searchguard.ssl.http.truststore_password: 
#searchguard.audit.type: internal_elasticsearch
searchguard.authcz.admin_dn:
   - ""

searchguard.ssl.transport.enable_openssl_if_available: true
searchguard.ssl.http.enable_openssl_if_available: true

searchguard.restapi.roles_enabled: ["SGS_ADMIN"]
#searchguard.audit.config.disabled_rest_categories: NONE
#searchguard.audit.config.disabled_transport_categories: NONE

########################## x-Pack #########################
xpack.license.self_generated.type: basic
#xpack.graph.enabled: false
xpack.ml.enabled: false
xpack.monitoring.enabled: false
##xpack.reporting.enabled: false
xpack.security.enabled: false

That’s not really how anonymous authentication works. Basically the flow is like:

  1. First we try to extract the user credentials from the request. In case of proxy auth, it’s the x-proxy-user and x-proxy-roles headers. In case of Basic Auth, it’s the Authorization HTTP header.
  2. If no credentials are found in the first configured authentication domain (proxy_auth_domain in your case) we continue with the next authentication domain (basic_internal_auth_domain in your case)
  3. If we were not able to extract credentials in any authentication domain , and anonymous authentication is enabled, then we create a user sg_anonymous with the backend role sg_anonymous_backendrole

Which means that we only fall back to anonymous authentication if no user credentials could be extracted. The question whether a user is actually mapped to a SG role in sg_roles_mapping.yml is not relevant.

Let me know if this helps!

Hi @jkressin ,

In this case I have one kibana instance without proxy auth, this redirect the request to sg_anonymous role.
Thanks for your clarification.

Best,
Yash

Hi @jkressin,

I have issue when I map sg_anonymous_backendrole to guest_tenant I get no date in the kibana. when I used authinfo API I got guest_tenant: false. May I know why I get “false” value for the tenant.

curl -k https://localhost:9200/_searchguard/authinfo?pretty
{
  "user" : "User [name=sg_anonymous, backend_roles=[sg_anonymous_backendrole], requestedTenant=null]",
  "user_name" : "sg_anonymous",
  "user_requested_tenant" : null,
  "remote_address" : "[::1]:46488",
  "backend_roles" : [
    "sg_anonymous_backendrole"
  ],
  "custom_attribute_names" : [ ],
  "sg_roles" : [
    "SGS_GUEST"
  ],
  "sg_tenants" : {
    "sg_anonymous" : true,
    "guest_tenant" : false
  },
  "principal" : null,
  "peer_certificates" : "0",
  "sso_logout_url" : null
}

sg_role.yml

SGS_ELK_ADMIN:
  description: "ELK Admin"
  cluster_permissions:
    - "SGS_UNLIMITED"
  index_permissions:
    - index_patterns:
        - "*"
      allowed_actions:
        - "READ"
    - index_patterns:
        - "?kibana*"
      allowed_actions:
        - "SGS_UNLIMITED"
  tenant_permissions:
    - tenant_patterns:
        - "elk_admin_tenant"
        - "guest_tenant"
      allowed_actions:
        - "SGS_KIBANA_ALL_WRITE"

SGS_GUEST:
  description: "guest only dashboards are accessible"
  cluster_permissions:
    - "SGS_CLUSTER_COMPOSITE_OPS_RO"
  index_permissions:
    - index_patterns:
        - "*"
      allowed_actions:
        - "SGS_UNLIMITED"
    - index_patterns:
        - "?kibana*"
      allowed_actions:
        - "SGS_UNLIMITED"
  tenant_permissions:
    - tenant_patterns:
        - "guest_tenant"
      allowed_actions:
        - "SGS_KIBANA_ALL_READ"

sg_roles_mapping.yml

SGS_ELK_ADMIN:
  reserved: false
  users:
    - "admin_user"
  description: "Maps ELK admin users to SGS_ELK_ADMIN"

SGS_GUEST:
  reserved: false
  backend_roles:
  - "sg_anonymous_backendrole"
  users:
  - "guest_user"
  description: "Guest users"

In above sg_role.yml I have user admin_user write access to guest_tenant to create dashboards and guest users (sg_anonymous and guest_user) will see the dashboards. When I tried to access via kibana usign sg_anonymous I could tenant available but no data is visible whereas if I login with `guest_user" I could see all the data in the tenant.
I have enabled anonymous auth in kibana and elasticsearch.

If you required any further information please do let me know.

Best,
Yash

Hm, this seems strange.

So to recap: You have created a user guest_user and mapped it to the SGS_GUEST role. And you have mapped the sg_anonymous_backendrole to this very same role.

If you use the guest user it works, but it does not work with the anonymous user, correct?

This seems strange since from the authinfo I can see that anonymout use is indee correctly mapped to the SGS_GUEST role.

(BTW: The SGS prefix means “Search Guard Static” and we use it to prefix the newly introduced built-in roles: https://docs.search-guard.com/7.x-35/roles-permissions#built-in-roles)

So, what would be interesting to see is the authinfo call for the guest user, and compare it with the anonymous one. Some questions:

  • Are both the anonymous and the guest user also mapped to the SGS_KIBANA_USER (which replaces the legacy sg_kibana_user role)?
  • Do you have the guest_tenant also configured in sg_tenants.yml (newly introduced in 7)?

The false in the authinfo call means that the tenant is read-only. This is a legacy output that some Kibana functionality still relies on, but which will be removed in some of the next SG versions.

@jkressin Apologies for the delayed response. I have fixed the roles by mapping the backed_roles with SGS_KIBANA_USER. when I try to access the kibana, I could see no dashboards but the dashboard are configured in the tenant. Looks like sg_backend_roles are are looking for apm-* index pattern. Please find the attached.


If you require any further information please do let me know.
Best,
Yash

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.