SW360 Configurations

Introduction

SW360 configurations are divided into two main categories: Non-changeable (File-based) and Changeable (Database-backed).

Applicable Property Files:

• sw360.properties (Core configurations)
• couchdb.properties (CouchDB and Lucene connectivity)
• orgmapping.properties (Organization mapping features)
• couchdb-test.properties (CouchDB test purpose)
• authorization/application.yml (Authorization server settings)
• rest/application.yml (Resource server settings)

Database Configurations:

Most of the SW360-related properties (UI settings and backend features) are now moved to a database and are accessible via a REST endpoint. These are divided into two containers:

• SW360_CONFIGURATION (Backend)
• UI_CONFIGURATION (Frontend)

More details can be found in the Database Configurations section below.

SW360.properties (/etc/sw360/sw360.properties)

The sw360.properties file contains properties that are considered non-changeable via the UI and require a Tomcat restart to take effect after updating.

couchdb.properties (/etc/sw360/couchdb.properties)

CouchDB and Lucene search configuration properties.

orgmapping.properties (/etc/sw360/orgmapping.properties)

This configuration file is used to activate the sw360 orgmapping feature.

couchdb-test.properties (/etc/sw360/couchdb-test.properties)

This file is used solely for the purpose of CouchDB database connectivity during testing.

authorization/application.yml (/etc/sw360/authorization/application.yml)

The Authorization Server handles OAuth2 tokens and client credentials.

server:
  port: 8090

couchdb:
  url: http://localhost:5984
  database: sw360oauthclients
  username: sw360
  password: sw360fossie

jwt:
  secretkey: sw360SecretKey
  auth:
    converter:
      principle-attribute: email

spring:
  jackson:
    serialization:
      indent_output: true
  main:
    allow-circular-references: true

sw360:
  cors:
    allowed-origin: ${SW360_CORS_ALLOWED_ORIGIN:#{null}}

security:
  customheader:
    headername:
      enabled: false
      intermediateauthstore: custom-header-auth-marker
      email: authenticated-email
      extid: authenticated-extid
  oauth2:
    resource:
      id: sw360-REST-API
  accesstoken:
    validity: 30
logging:
  level:
    org.springframework.security: DEBUG

rest/application.yml (/etc/sw360/rest/application.yml)

The Resource Server provides the SW360 REST API.

server:
  servlet:
    context-path: /

management:
  endpoints:
    web:
      base-path: /
      exposure:
        include: health,info
      path-mapping:
        health: /api/health
        info: /api/info
  endpoint:
    health:
      show-details: always
      enabled: true
    info:
      enabled: true
  security:
    enabled: true
  health:
    diskspace:
      enabled: true    # Disable to hide sensitive system information
    ping:
      enabled: true
    ssl:
      enabled: false   # Disabled as not used

spring:
  profiles:
    active: SECURITY_MOCK
  application:
    name: resource
  servlet:
    multipart:
      max-file-size: 500MB
      max-request-size: 600MB
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: http://localhost:8080/authorization/oauth2/jwks
          jwk-set-uri: http://localhost:8080/authorization/oauth2/jwks

#logging:
#  level:
#    org.springframework.security: DEBUG
#    org.springframework.security.oauth2: DEBUG
#    org.springframework.security.oauth2.provider.endpoint: DEBUG
#    org.springframework.security.oauth2.provider.error: DEBUG
#    org.springframework.security.oauth2.provider.token: DEBUG
#    org.springframework.security.oauth2.provider.token.store: DEBUG
#    org.springframework.security.oauth2.provider.token.store.jwk: DEBUG

jwt:
  auth:
    converter:
      resource-id: sw360-rest-api
      principle-attribute: email

sw360:
  thrift-server-url: ${SW360_THRIFT_SERVER_URL:http://localhost:8080}
  base-url: ${SW360_BASE_URL:http://localhost:8080}
  test-user-id: admin@sw360.org
  test-user-password: 12345
  couchdb-url: ${SW360_COUCHDB_URL:http://localhost:5984}
  cors:
    allowed-origin: ${SW360_CORS_ALLOWED_ORIGIN:#{null}}

blacklist:
  sw360:
    rest:
      api:
        endpoints:

springdoc:
  api-docs:
    enabled: true
    path: /v3/api-docs
    security:
      oauth2:
        enabled: true
  swagger-ui:
    enabled: true
    path: /index.html
    security:
      oauth2:
        enabled: true
  default-consumes-media-type: application/json
  default-produces-media-type: application/hal+json

Database Configurations

A significant portion of SW360’s configuration is now stored in the database. These settings are dynamic and can be managed via REST API endpoints without requiring a full system restart in most cases.

The configurations are partitioned into two containers:

1. SW360_CONFIGURATION: Backend and core logic settings.
2. UI_CONFIGURATION: Frontend and UI-specific settings (categories, roles, platforms, etc.).

SW360 Container (Backend)

UI Container (Frontend)

Configuration Management via the UI

Since these configurations are accessible over REST API, they can be manipulated directly from the frontend.

From an ADMIN account, goto the frontend, under Admin section, you’d find Configurations tab, which allows you to manage these configurations. There will be 2 tabs for each container defined bellow which helps you mainpulate these configurations directly from the UI.

Configuration Management via REST API

Configurations can be retrieved and updated using the following endpoints provided by the Resource Server.

Retrieve Configurations

• Get All Configurations: GET /configurations?changeable=<bool>
  • changeable=true: Returns keys managed in the database.
  • changeable=false: Returns keys defined in sw360.properties.
• Get Container-Specific Configurations: GET /configurations/container/{configFor}?changeable=<bool>
  • configFor: SW360_CONFIGURATION (Backend) or UI_CONFIGURATION (Frontend).

Update Configurations

• Update Database Configs: PATCH /configurations/container/{configFor}
  • Content-Type: application/json
  • Description: Updates one or more keys in the specified container.

Reloading Policy

• Database Configs (Changeable): Updates are applied immediately upon successful PATCH operation.
• File Configs (Non-changeable): Updates must be made by editing the sw360.properties file on the server. A Tomcat restart is required to load the new values.