The library and sample application can be downloaded from the Maven repository. In addition, build artifacts are composed and held at the GitLab repository of the project. For latest published builds see [dariahsp-core](https://gitlab.rz.uni-bamberg.de/dariah/dariahsp/-/jobs/artifacts/v2.0/browse/dariahsp-core/build/libs/?job=build) and [dariahsp-sample-boot](https://gitlab.rz.uni-bamberg.de/dariah/dariahsp/-/jobs/artifacts/v2.0/browse/dariahsp-sample-boot/build/libs/?job=build). Please not that while a new version is being prepared, a 404 error is issued when following these links.
The library and sample application can be downloaded from the [Maven repository](https://minfba.de.dariah.eu/nexus/#browse/browse:minfba-central:eu%2Fdariah%2Fde%2Fdariahsp-core). In addition, build artifacts are also composed and held at the GitLab repository of the project. For the latest published builds see [dariahsp-core](https://gitlab.rz.uni-bamberg.de/dariah/dariahsp/-/jobs/artifacts/v2.0/browse/dariahsp-core/build/libs/?job=build) and [dariahsp-sample-boot](https://gitlab.rz.uni-bamberg.de/dariah/dariahsp/-/jobs/artifacts/v2.0/browse/dariahsp-sample-boot/build/libs/?job=build) respectively.
Please note that while new artifacts are being prepared, a 404 error is issued when following these links. In occurring cases, we advise to wait for the completion of the build and download the fresh artifacts thereafter.
## 3. Security concepts and entry points
...
...
@@ -115,49 +117,75 @@ One component requires _adaption_ in implementing applications:
## 4. Configuration
### Minimal working configuration
A minimal working configuration enables the local authentication method and provides local user accounts.
Configuration properties are specified here and in the sample boot app by means of anh according YAML configuration file.
## Local user accounts
The library supports a local authentication method that is purely based on application configuration properties. A working example including all configurable aspects:
## 4.1 Minimal working configuration
A minimal working configuration enables the **local authentication** method and defines **local user accounts**. The following configuration snippet includes an *admin* user with a specified BCrypt-encrypted password.
```yaml
#Minimal working sample configuration with local authentication enabled and one configured user
A more sophisticated configuration of the local authentication method could involve roles and role mappings along with a configured hierarchy between the roles
In order to facilitate BCrypt encryption of passwords without having to rely on online generators, the `dariah-core` library implements a CLI-based generator. Due to required dependencies, usage of the so called fatjar is required, which can be downloaded from the [build artifacts](https://gitlab.rz.uni-bamberg.de/dariah/dariahsp/-/jobs/artifacts/v2.0/browse/dariahsp-core/build/libs/?job=build) or the [Maven repository](https://minfba.de.dariah.eu/nexus/#browse/browse:minfba-central:eu%2Fdariah%2Fde%2Fdariahsp-core).
Role management and configuration in the dariahsp-core library follow three basic concepts:
* User accounts *can provide information on roles*.
* in case of the *SAML authentication* method, these roles are managed externally within the Identify Providers
* for *local authentication*, roles are attached as attributes to user specifications
* Due to limited control of user roles in external scenarios (SAML), user roles are mapped to permission definitions that are fully under control of an implementing application; configured `permissionDefintions`:
* specify an internal name of the `permissionSet` against which security can be applied
* define a numeric permission `level` against which authorization can be validated (e.g. level must be gte 50)
* identify actual mappings to the (potentially) external roles; mapping configuration is specified per authentication method (currently `local` or `saml`)
* A hierarchy of permission definitions can be specified in order to authorize against minimal permission sets. In the sample configuration below, a security expression checking for a permission `ROLE_CONTRIBUTOR` is satisfied by both the `admin` and `contributor` users due to the configured permission hierarchy.
```yaml
auth:
#settings under roleHierarchy and roleDefinitions apply to all supported authentication methods
#Enabled local authentication method with three configured users
local:
enabled:true
authorizerName:local
#Same password for each user: 1234
users:
...
...
@@ -172,27 +200,106 @@ auth:
roles:["application_user"]
```
## 4.3 SAML-based authentication
The configuration sample below shows important attributes that should be adapted for enabling SAML-based authentication.
### Java Keystore
Even with the *local* authentication method, the dariahsp-sample application requires the configuration of a Java keystore (jks). This is mainly due to the SAML metadata generation functionality, which is available when local logins are used in order to help with installations of SAML service providers: starting the sample application in local authentication mode, the home screen of the application shows two links *SAML metadata...*, which support SAML metadata management (see SAML section below).
```yaml
auth:
# This base URL must indicate the externally visible FQDN
Provide the URL of the desired **IdP or metadata federation**. In case of DARIAH/CLARIAH implementations, all current services use the URL as detailed in the sample above.
### 4.3.2 Java KeyStore (JKS)
This library requires an existing Java KeyStore (JKS) that contains a private/public keypair that can be used for signature and encryption purposes. Depending on the addressed IdP or proxy, different requirements to used keys could apply. Once setup, set the appropriate configuration parameters of `saml.keystore.{path,pass,alias,aliaspass}`
#### Simple KeyStore generation
If you are setting up a DARIAH/CLARIAH service, a keystore - along with the required keypair can be created as such:
Based on a X.509 keypair and certificate chains, a keystore can easily be consolidated with `openssl` and the `keytool` (comes with Java installation). The followings steps show the commands for the example of the keystore for minfba.de.dariah.eu and the appropriate input. Please modify accordingly:
#### 1. Convert pem/pem keypair to p12 for easier input
1. Convert pem/pem keypair to p12 for easier input
For the -name argument make sure to chose as *name* the later alias of the keypair in the keystore.
#### 2. Import p12 keypair and create Java keystore
2. Import p12 keypair and create Java keystore
Specified in the following step with the -alias argument note the reuse of the same key name as above. Basically this step imports an existing PKCS based "keystore" into a newly created jks.
In the particular DARIAH-DE case this means 1) the chain of our keypair and 2) the trusted SAML metadata provider keychains of the [DFN AAI](https://www.aai.dfn.de/teilnahme/metadaten/).
A convenient GUI-based option to view and edit Java keystore can be found in the [KeyStore Explorer](http://keystore-explorer.org/)
### Local user accounts
Local user accounts are configured in the central configuration file of the sample application. Passwords are encoded as Bcrypt hashes. In order to create your own hashes a convenience method has been implemented within the dariahsp-core library. As there are some required dependencies, you can download the latest [dariahsp-core-*-jar-with-dependencies.jar](https://minfba.de.dariah.eu/artifactory/list/dariah-minfba-snapshots/eu/dariah/de/dariahsp-core/).
