Skip to content

Operators guide ‐ v1.0.0

Jump to bottom Edit New page
Open Science Data edited this page Dec 8, 2023 · 2 revisions

Open Science Catalog

Operators Guide - v1.0.0

Table of Contents

Operator's Guide

This document shall depict common operation scenarios and help guiding operators.

Whenever the operator has to interact with the cluster objects directly, he has to have a correct setup of the cluster connection. This usually involves having an SSH tunnel via the bastion host, so only configured personnel can establish a connection.

This can be established with the following command:

sshuttle -r "[email protected]" "192.168.100.0/24"

For all accessing the kubernetes cluster, a correct kubeconfig file must be set up and used. All commands in this document assume that this is set up properly.

There are two instances of the OSC facilities on the cluster, live and staging. Each has a corresponding namespace. Again, the operator has to make sure that he is working on the correct one.

User Management

Custom Attributes Setup

Reference: https://gluu.org/docs/gluu-server/4.1/admin-guide/attribute/#custom-attributes

Connect to opendj pod

kubectl -n\<namespace\> exec -it um-login-service-opendj-init-ss-0 -- sh

Edit file /opt/opendj/config/schema/77-customAttributes.ldif

attributeTypes: ( 1.3.6.1.4.1.48710.1.3.1405 NAME 
'OSCDataOwner'
  DESC 'Open Science Catalog Data Owner'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  X-ORIGIN 'Gluu custom attribute' )

Then, add the new custom attribute to thegluuCustomPersonobjectClasses.

MAY ( OSCDataOwner $ telephoneNumber [...]

This custom attribute can then be used in the admin interface configuration (see following chapter).

Configuration

Gluu admin login defaults: username: admin password: admin_Abcd1234# (to be changed after first login)

Organization Configuration

Organization Settings

  • Organization name: Open Science Catalog
  • change logo/favicon

Manage Custom Scripts

  • enable User Registration -> user_registration
  • set Custom property "enable_user" to true
  • set Custom property "post_registration_redirect_uri" to "<frontend url>/login" to enable redirect after successful registration

Attributes

  • Set Attributes to inactive that are not needed (e.g. "displayName")
  • Prerequisite: Added custom OSCDataOwner attribute to LDAP (see Custom Attributes Setup chapter)
  • Add custom OSCDataOwner attribute to oxTrust (https://gluu.org/docs/gluu-server/4.1/admin-guide/attribute/#add-the-attribute-to-oxtrust) by registering a new attribute (provide "OSCDataOwner" as name and "Boolean" as type, and "OSCDataOwner" as oxAuth claim name)
  • Now users can be assigned as OSCDataOwner

OpenID Connect

Scopes

Add the OSCDataOwner claim to the profile scope

Clients

Add client with following settings:

OPENID CONNECT CLIENTS DETAILS
------------------------------
- \*\*Name:\*\* OSCUserClient
- \*\*Client ID:\*\* 2af21e66-bd47-4894-b91e-2f3d6c07d99e
- \*\*Subject Type:\*\* pairwise
- \*\*ClientSecret:\*\* XXXXXXXXXXX
- \*\*Application Type:\*\* web
- \*\*Persist Client Authorizations:\*\* true
- \*\*Pre-Authorization:\*\* false
- \*\*Authentication method for the Token Endpoint:\*\* client\_secret\_post
- \*\*Logout Session Required:\*\* false
- \*\*Include Claims In Id Token:\*\* true
- \*\*Disabled:\*\* false
- \*\*Logout Redirect URIs:\*\* [[http://localhost:3000/](http://localhost:3000/),[https://eoepca.github.io/open-science-catalog-frontend/](https://eoepca.github.io/open-science-catalog-frontend/),[https://staging.185.52.192.220.nip.io/](https://staging.185.52.192.220.nip.io/), https://staging.opensciencedata.esa.int/\*]
- \*\*Login Redirect URIs:\*\* [[http://localhost:3000/oauth-callback](http://localhost:3000/oauth-callback),[https://eoepca.github.io/open-science-catalog-frontend/oauth-callback](https://eoepca.github.io/open-science-catalog-frontend/oauth-callback),[https://staging.185.52.192.220.nip.io/oauth-callback](https://staging.185.52.192.220.nip.io/oauth-callback), https://staging.opensciencedata.esa.int/oauth-callback\*]
- \*\*AccessTokenSigningAlg:\*\* RS256
- \*\*Scopes:\*\* [eoepca, permission, is\_operator, email, user\_name, openid, automated, profile]
- \*\*Grant types:\*\* [client\_credentials, password, implicit, refresh\_token, urn:ietf:params:oauth:grant-type:uma-ticket, authorization\_code]
- \*\*Response types:\*\* [id\_token, token, code]

* change URLs accordingly in production deployment To provide multiple Redirect Login URIs, one needs to select a Sector Identifier (Test Sector Identifier is fine) and add the URIs there

User Roles

Assign a the OSCDataOwner User role to an existing user

In order to change the OSCDataOwner attribute to an existing user, the operator needs to log in as an administrator in the Gluu administrator interface. Then the user to be edited needs to be found in the "Manage People" section of the interface. When the user to be edited has been selected, in the gluuCustomPerson tab, the OSCDataOwner attribute can be selected, which will be subsequently added to the user profile. In order to save the changes, the "Update" button has to be used.

operators-guide1

Upload a new set of customizations of the Login Service

When there is a new set of customizations of the Login Service, these need to be installed manually. For this purpose, the customizations need to be bundled in archive bundles and then uploaded as kubernetes ConfigMaps. The following code listing shows how to effectively achieve this.

cd kubernetes/$NAMESPACE/user-management/customizations/oxauth
tar -czvf ../../customizations\_oxauth.tar.gz .
cd ../oxtrust
tar -czvf ../../customizations\_oxtrust.tar.gz .
cd ../../
kubectl create configmap front-customizations -n $NAMESPACE --from-file=customizations\_oxauth.tar.gz --from-file=customizations\_oxtrust.tar.gz -o yaml --dry-run | kubectl replace -f -
OXAUTH=$(kubectl get deployment -n $NAMESPACE | grep oxauth | awk '{print $1}')
OXTRUST=$(kubectl get statefulsets -n $NAMESPACE | grep oxtrust | awk '{print $1}')
kubectl scale deployment $OXAUTH --replicas 0 -n $NAMESPACE
kubectl scale statefulsets $OXTRUST --replicas 0 -n $NAMESPACE
sleep 5
kubectl scale deployment $OXAUTH --replicas 1 -n $NAMESPACE
kubectl scale statefulsets $OXTRUST --replicas 1 -n $NAMESPACE

IDP Configuration Management

Adding a new IDP Authentication Service

Please refer to the following document External IDPs · EOEPCA/um-login-service Wiki (github.com)

ESA EOIAM deployment

In addition to the guidance above here are the steps used to configure ESA EOIAM deployment. See also OPEN board - Agile Board - Jira (atlassian.net)

The procedure to add external IDPs to the owned IAM, based on Gluu would be:

-Login as admin in the hostname for the IAM Gluu UI. -Navigate to the Passport > Providers section and click the +Add New Provider button -Introduce the required information. For the EOIAM the configuration would be the following:

Provider ID: eoiam
Display Name: esa EOIAM
Type: openidconnect
Passport.js strategy: passport-openidconnect
Mapping: openidconnect-default
Authenticate Params:
Logo path: logos available at \<https://i.imgur.com/FR7BJa0.png\>
Is Enabled: true
Request For Email: optional
Email linking: true
Providers Options
   authorizationURL = 
\<https://eoiamref-idp.eo.esa.int/oauth2/authorize\>
   clientID = \<provided by EOIAM\>
   clientSecret: = \<provided by EOIAM\>
   issuer = \<https://eoiamref-idp.eo.esa.int/oauth2/token\>
   scope = openid profile
   tokenURL = \<https://eoiamref-idp.eo.esa.int/oauth2/token\>
   userInfoURL = \<https://eoiamref-idp.eo.esa.int/oauth2/userinfo\>

-Then the authentication method needs to be set to use the passport_social in order to update the login page to show external IdP options. This can be achieved in Gluu UI in Configuration

\> Manage Authentication \> Default Authentication Method.

-Possible Error: If the login is not working after selecting the external IdP option, ensure that the other Identity Providers in Gluu have their values filled, (i.e. github option should have at least a value set in their client credentials.) One empty value in any provider will break the login with all the rest so take that in mind.

Resource Management

Resource Catalog

Reset the Resource Catalog database

Sometimes it is necessary to reset the contents of the Resource Catalog, e.g when updating to a new version of the software.

kubectl exec -it statefulset/data-access-database
$ su postgres
$ psql -d pycsw
\> delete from records;

Harvesting

Harvesting in the OSC is a synchronization process between the static and dynamic catalog. The static catalog is rebuilt whenever the contents of the main branch of the metadata repository changes. In order to be reflected in the dynamic catalog, these changes must be harvested.

Triggering a manual harvest

Sometimes it may be necessary to trigger a manual harvest, e.g when the contents of the dynamic catalog have been cleared manually, and want to be refilled as soon as possible.

In order to trigger a harvest, the operator has to manipulate the pod on the cluster, and

kubectl -n ${NAMESPACE} exec -it deployment/data-access-harvester -- harvester harvest --config-file /config.yaml OSC-Static
Add a custom footer
Add a custom sidebar
Clone this wiki locally