Date: Thu, 28 Mar 2024 11:03:03 +0000 (UTC) Message-ID: <2015255988.6175.1711623783340@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6174_1209953907.1711623783340" ------=_Part_6174_1209953907.1711623783340 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The SAML Metadata Configuration Manager (MCM) is built as a Java Spring = Boot ( https://spring.io/projects/spring= -boot ) application. It can be run as a standalone we= b application that has Tomcat embedded in it. The same WAR file can be depl= oyed into an external servlet container (standalone Tomcat etc). It can als= o be deployed using a Docker image. And in the Docker realm, the project al= so provides a full "testbed environment" that includes a database, an IdP, = a LDAP server, etc.
The MCM currently supports three distinct roles:
The following are some things that are useful to consider and know regar= dless of which deployment model you choose to go with.
Much of the behavior of the MCM can be set and controlled through proper= ties files which can be in one or both of the following formats:
The MCM comes with basic examples of both types of properties files.
The example application.properties file includes the core sett= ings for authentication, database connection information, users file, the d= irectory/location settings for where the MCM should write out the metadata = files and metadata-providers.xml file it manages, etc.
The example application.yml file contains all the settings tha= t impact the information, options, list elements, etc. that are actually sh= own in the UI.
There is no reason that you need to keep that distinction; you could man= age everything through a single properties or YAML-format file if you wante= d. On the other hand, it can be a convenient distinction to keep the core "= internal/baked-in settings" distinct from the "front-end/UI" settings. By d= efault, property sources named `application.properties` and `application.ym= l` will be recognized by Spring Boot and merged at runtime to form a finali= zed `Environment` object holding all the properties gathered from all the p= roperty sources locations. Details on the properties that can/should be con= figured are detailed later in this document.
There are multiple "Testbed" environments that you can run that are avai= lable in the repository (in the testbed folder of the repository project). = The instances include various database setups as simple examples of how to = quickly run the application configured for each database (Maria, Postgres, = SQL Server, MySQL).
There is also a fully integrated example in the testbed folder in the&nb= sp;integration folder. It includes the:<= /p>
To setup the "Testbed", you will need to:
Clone the repository:
|
docker compose up
Once Docker has completed the startup of all containers you can access t= he SAML MCM login screen with the following URL:
https://shibui.unicon.local
The Docker image of the SAML MCM follows the TIER Docker packaging stand= ards, utilizing CentOS7, the Zulu JDK, supervisor, and the TIER Beacon conf= iguration.
Basic usage:
docker = run -p 8080:8080 -v <your local application.properties>:/opt/shibui/a= pplication.properties i2incommon/shib-idp-ui
You will want to create a =
local application.properties file that contains the core application settin=
gs you want overriding the defaults that are in the SAML MCM war file. Your=
file should be mounted at the location /opt/shibui/application.properties.=
The current set of supported properties can be found here.
Note: If you did not set an explicit password in your local application.=
properties then you will have to look at the startup "console messages" and=
find the one generated at startup. Look for the line: <=
strong>Using generated security password:. The username is:&=
nbsp;user
The SAML MCM war file includes an emb= edded Tomcat mode allowing you to run the application without any external = dependencies beyond your configuration overrides.
The following example shows how you c= an override the default database and use mariadb instead. Example app= lication.yml(s) for configuring common RDBMS can be found in the github repository.
shibui: default-password: "{noop}pass" spring: datasource: platform: mysql driver-class-name: org.mariadb.jdbc.Driver =09url: jdbc:mariadb://localhost:3306/shibui =09username: shibui =09password: shibui jpa: properties: =09 hibernate: =09 dialect: org.hibernate.dialect.MariaDB103Dialect
Note: You need to list an "encryption scheme" for the default-pass= word which is what the '{noop}' is preceding it. More info on the enc= ryption scheme can be found h= ere.
Then you will run the war and tell Spring Boot where to find the externa= lized application.yml.
java -X= mx1g -jar shibui-1.18.0.war --spring.config.additional-location=3Dfile:/etc= /shibboleth-ui/
You can then access the application on http://localho=
st:8080 and login as root with the password you set in application.yml<=
br>
This section describes how to deploy Shibboleth UI application as web ar= chive with external configuration sources which override default configurat= ion setting embedded in Shibboleth UI war to external Tomcat servlet contai= ner.
Shibboleth UI is a Spring Boot web application which supports all standa= rd Spring Boot property sources and configuration options. So, let's assume= that our external configuration directory is `/etc/shibboleth-ui`. By defa= ult, property sources named `application.properties` and `application.yml` = will be recognized by Spring Boot and merged at runtime to form a finalized= `Environment` object holding all the properties gathered from all the prop= erty sources locations and then available to configure Shibboleth UI web ap= plication. All the standard Spring Boot property sources precedence rules a= pply here, but for our purposes we need to know that Shibboleth UI war depl= oyed to external servlet container, embeds the set of default configuration= properties on runtime classpath in `application.properties` file and then = any standard property could be overridden by externalizing them in addition= al `application.properties` or `application.yml` files. So, back to our exa= mple, let's assume we use `/etc/shibboleth-ui/application.yml` file to run = our Shibboleth UI application and connect to MariaDB RDBMS instead of a def= ault embedded H2 database that is configured in `application.properties` em= bedded in shibui.war which would be deployed to external servlet container.= The sample `/etc/shibboleth-ui/application.yml` containing properties to c= onnect to MariaDB instance would look like this:
shibui:
default-password: "{noop}pass"
spring:
&= nbsp; datasource:
platform: mysql
driver-= class-name: org.mariadb.jdbc.Driver
url: jdbc:mariadb://localhost:3306/s= hibui
username: shibui
password: shib= ui
jpa:
properties:
hibe= rnate:
dialect: org.hibernate.dialect.MariaD= BDialect
Then you would tell Spring Boot where to find externalized `application.= yml`. That would be accomplished by passing `spring.config.additional-locat= ion` property. For Tomcat it could be accomplished in `$CATALINA_HOME/bin/s= etenv.sh` file like so:
`export JAVA_OPTS=3D"$JAVA_OPTS -Dspring.config.additional-location=3Dfile:/etc/shibboleth-ui/"`
then deploy `shibui.war` to external Tomcat and then you could access ap= plication on `http://localhost:8080` with `root/pass` username/passwor= d combination
So, now you could use externalized `/etc/shibboleth-ui/application.yml` = file to override/configure any property available to Shibboleth UI web apli= cation independent of what is embedded in shibui.war deployed to external T= omcat container.
To deploy under HTTPS, if the external Tomcat is used, the standard conf= iguration of Tomcat HTTP connector applies here. When deploying in the embe= dded Tomcat mode, in order to enable HTTPS, the following configuration pro= perties (sample) should be used:
server:
ssl:
key-store: /etc/shibui/keystore.p12
ke= y-store-password: password
key-store-type: pkcs12
key-alias: = tomcat
key-password: password
port: 8443
Note that `keys= tore.p12` would contain a valid SSL certificate
One key decision that you will need to make is how to control authentica= tion of users of the ShibUI. If you use the default user or a users file, n= ote the following on defining passwords
Currently, the supported values for ENCRYPT_SCHEME are either:
For more info on supported Spring Security's password storage formats, s= ee: https://docs.spring.io/spring-security/site/docs/current/reference/htm= lsingle/#pe-dpe-format
Simple, recommended only for secure environments (private networks a= vailable accessible via VPN or local access) with very limited user base (1= -2 admin)
If you "do nothing", the ShibUI will set up a single "root" (that's the username) user, with a password it will generate the first= time you run it. That password should be displayed in the console log as t= he UI starts up =E2=80=93 but you probably really don't want to rely on tha= t. If you are going to go with this option, you should set the password for= that single "root" user in the configuration file.
application.properties: shibui.default-passwor= d =3D {ENCRYPT_SCHEME}password
Simple, recommended only for secure environments (private networks a= vailable accessible via VPN or local access) with limited user base (where = users will not share a single login)
Obviously, you could start playing with the ShibUI, and even have multip= le people use that same single root account. But likely just about any depl= oyer is going to want to instead supply a "users file", and/or integrate yo= ur Shibboleth IdP as the authentication source.
Even if you are going to do the latter, you really need to "bootstrap" t= he Shibboleth IdP integration with at least a single user in that "users fi= le". The reason for that is you need to establish at least one user who has= the ROLE_ADMIN role.<= /p>
The ShibUI application does support accepting the UI role for a user as = an attribute from the Shibboleth IdP. If the IDP user information is not ab= le to provide roles as listed above, you will need to configure a users fil= e with at least one username (that will be passed from the IdP) listed with= the ROLE_ADMIN role. You can configure the users file to have as many user= s as you want. The format of the users file is the following set of fields,= separated by commas:
username,{ENCRYPT_SCHEME}password,firstname,lastname,ROLE_VALUE,= email
Example Users File
The property name that is used to indicate users file is:
**(the name of the file does not matter)
Every time you restart the ShibUI, it will read in that file, and update= the internal user database entries with any changes. Password is still a r= equired field, but won't be used if your Shibboleth IdP is being used to au= thenticate your ShibUI users.
The property name that is used to indicate users file is:
**(the name of the file does not matter)
Every time you restart the ShibUI, it will read in that file, and update= the internal user database entries with any changes. Password is still a r= equired field, but won't be used if your Shibboleth IdP is being used to au= thenticate your ShibUI users.
Recommended when a large volume of users needs to access the ShibUI = or the application will be publicly accessible
Many deployers will presumably want to use their Shibboleth IdP for auth=
entication. The ShibUI includes a Java-based SAML SP based on the Pac4j ( https://www.pac4j.org ) library (SA=
ML support built on top of the Shibboleth Consortium's OpenSAML software). =
This is pretty easy to configure, but it requires doing the following steps=
, before you start up the ShibUI.
Note: the settings for where Pac4j will store its SAML-related certifica=
tes ( shibui.pac4j.keystorePath&nb=
sp;and related passwords) and SP metadata (
application.properties config example
# Enabl= e Pac4j, should generate its own certs and metadata on first attempt to use shibui.pac4j-enabled =3D true shibui.pac4j.keystorePath =3D /full/path/to/ShibUI/samlKeystore.jks shibui.pac4j.keystorePassword =3D whatever_you_want shibui.pac4j.privateKeyPassword =3D whatever_you_want shibui.pac4j.serviceProviderMetadataPath =3D /full/path/to/ShibUI/sp-metada= ta.xml shibui.pac4j.serviceProviderEntityId =3D http(s)://entityID/url/for/ShibUI =20 # Path to file containing Shibboleth IdP metadata shibui.pac4j.identityProviderMetadataPath =3D /full/path/to/ShibIdP/idp-met= adata.xml shibui.pac4j.forceServiceProviderMetadataGeneration =3D false shibui.pac4j.callbackUrl =3D https://localhost:8443/callback =E2=86= =90 Note this depends on the URL at which the ShibUI will be available =20 # Following is the max allowed age of AuthnInstant allowed # in SAML response sent to Pac4j SP shibui.pac4j.maximumAuthenticationLifetime =3D 36000 =20 # SAML attribute mapping. Name of the attribute the IdP will # supply that the UI should use to populate its internal user store. # As long as it least one Shibboleth IdP username matches up with at least = one # in the supplied users file that has the Admin (ROLE_ADMIN) roel, that per= son # can manage the role assignment of all other users thru the UI directly. shibui.pac4j.simpleProfileMapping.username =3D urn:oid:0.9.2342.19200300.10= 0.1.1 shibui.pac4j.simpleProfileMapping.firstname =3D urn:oid:2.5.4.42 shibui.pac4j.simpleProfileMapping.lastname =3D urn:oid:2.5.4.4 shibui.pac4j.simpleProfileMapping.email =3D urn:oid:0.9.2342.19200300.100.1= .3 |
application.yml config example
shibui: pac4j-enabled: true # Enable Pac4j, should generate its own certs and met= adata on first attempt to use pac4j: keystorePath: /full/path/to/ShibUI/samlKeystore.jks keystorePassword: whatever_you_want privateKeyPassword: whatever_you_want serviceProviderMetadataPath: /full/path/to/ShibUI/sp-metadata.xml serviceProviderEntityId: http(s)://entityID/url/for/ShibUI identityProviderMetadataPath: /full/path/to/ShibIdP/idp-metadata.xml forceServiceProviderMetadataGeneration: false callbackUrl: https://localhost:8443/callback maximumAuthenticationLifetime: 3600000 simpleProfileMapping: username: urn:oid:0.9.2342.19200300.100.1.1 firstname: urn:oid:2.5.4.42 lastname: urn:oid:2.5.4.4 email: urn:oid:0.9.2342.19200300.100.1.3 |
Once you have those settings in place, then start up the ShibUI, and try= to access the dashboard, you should be directed to the configured IdP for = authentication. The IdP should present an error, because you have not yet c= onfigured it with metadata and attribute release for the ShibUI.
As the files you provided for SP keystore and metadata were "non-existen= t", Pac4j will generate those. So now you will ha= ve a ShibUI SP metadata file (for ShibUI) that you can add to the IdP, and = configure attribute release to the ShibUI entityID, matching up with the at= tribute mapping you configured above.
Re-try to access the ShibUI dashboard again, and you should be "good to = go".
The above process should work no matter what deployment model you choose= . What will be different between the models is how the ShibUI interacts wit= h the file system, and its expectations as to where various files will be f= ound.
This set of examples shows the basic configuration for each of the datab= ase types - please adjust server-names/addresses/ports/db-name/dbusers acco= rdingly with your database. Defaults shown below
Support for MySQL, Postgres, MariaDB, and SQL Server are available
database configuration
spring: profiles: include: datasource: platform: mysql driver-class-name: org.mariadb.jdbc.Driver url: jdbc:mariadb://db:3306/shibui username: shibui password: shibui jpa: properties: hibernate: dialect: org.hibernate.dialect.MariaDB103Dialect =20 ---------------------------------------------------------------- =20 spring: profiles: include: datasource: platform: mysql driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://db:3306/shibui username: shibui password: shibui jpa: properties: hibernate: dialect: org.hibernate.dialect.MySQL8Dialect =20 ---------------------------------------------------------------- =20 spring: profiles: include: datasource: platform: postgres driver-class-name: org.postgresql.Driver url: jdbc:postgresql://db:5432/shibui username: shibui password: shibui jpa: properties: hibernate: dialect: org.hibernate.dialect.PostgreSQL95Dialect =20 ---------------------------------------------------------------- =20 spring: profiles: include: datasource: platform: sqlserver driver-class-name: com.microsoft.sqlserver.jdbc.SQLServerDriver url: jdbc:sqlserver://db:1433 username: shibui password: shibui jpa: properties: hibernate: dialect: org.hibernate.dialect.SQLServerDialect |
This is a reflection of the default application.=
properties
file included in the distribution. Note=
that lines beginning with #
are commented out.
# Serve= r Configuration #server.port=3D8080 =20 # Logging Configuration #logging.config=3Dclasspath:log4j2.xml =20 #logging.level.org.springframework.security=3DINFO logging.level.org.springframework=3DINFO logging.level.edu.internet2.tier.shibboleth.admin.ui=3DINFO =20 spring.main.allow-bean-definition-overriding=3Dtrue =20 # Database Credentials spring.datasource.username=3Dshibui spring.datasource.password=3Dshibui =20 # Database Configuration H2 spring.datasource.url=3Djdbc:h2:mem:shibui;DB_CLOSE_DELAY=3D-1;DB_CLOSE_ON_= EXIT=3DFALSE spring.datasource.platform=3Dh2 spring.datasource.driverClassName=3Dorg.h2.Driver spring.jpa.database-platform=3Dorg.hibernate.dialect.H2Dialect spring.h2.console.enabled=3Dtrue spring.h2.console.settings.web-allow-others=3Dtrue =20 # spring.jackson.default-property-inclusion=3Dnon_absent spring.jackson.default-property-inclusion=3DNON_NULL spring.jackson.mapper.accept-case-insensitive-enums=3Dtrue =20 # Database Configuration PostgreSQL #spring.datasource.url=3Djdbc:postgresql://localhost:5432/shibui #spring.datasource.driverClassName=3Dorg.postgresql.Driver #spring.jpa.properties.hibernate.dialect=3Dorg.hibernate.dialect.PostgreSQL= Dialect =20 #Maria/MySQL DB #spring.datasource.url=3Djdbc:mariadb://localhost:3306/shibui #spring.datasource.driverClassName=3Dorg.mariadb.jdbc.Driver #spring.jpa.properties.hibernate.dialect=3Dorg.hibernate.dialect.MariaDBDia= lect =20 # Liquibase properties spring.liquibase.enabled=3Dfalse =20 # Hibernate properties # for production never ever use create, create-drop. It's BEST to use valid= ate spring.jpa.hibernate.ddl-auto=3Dupdate spring.jpa.hibernate.naming.implicit-strategy=3Dorg.hibernate.boot.model.na= ming.ImplicitNamingStrategyJpaCompliantImpl spring.jpa.show-sql=3Dfalse spring.jpa.properties.hibernate.format_sql=3Dfalse spring.jpa.properties.hibernate.check_nullability=3Dtrue spring.jpa.hibernate.use-new-id-generator-mappings=3Dtrue =20 #Envers versioning spring.jpa.properties.org.hibernate.envers.store_data_at_delete=3Dtrue =20 #Needed in the latest versions of Spring Boot when doing manual transaction= management like we do in envers versioning code spring.jpa.properties.hibernate.current_session_context_class=3Dorg.springf= ramework.orm.hibernate5.SpringSessionContext =20 # Set the following property to periodically write out the generated metada= ta files. There is no default value; the following is just an example # shibui.metadata-dir=3D/opt/shibboleth-idp/metadata/generated shibui.logout-url=3D/dashboard =20 # spring.profiles.active=3Ddefault =20 ## Default root user can be set in application.yml or here - setting in bot= h places can be undeterministic ## Default password must be set for the default user to be configured and s= etup #shibui.default-password=3D{noop}somepassword shibui.default-rootuser=3Droot =20 shibui.metadata-sources-ui-schema-location=3Dclasspath:metadata-sources-ui-= schema.json shibui.entity-attributes-filters-ui-schema-location=3Dclasspath:entity-attr= ibutes-filters-ui-schema.json shibui.nameid-filter-ui-schema-location=3Dclasspath:nameid-filter.schema.js= on =20 #Actuator endpoints (info) # Un-comment to get full git details exposed like author, abbreviated SHA-1= , commit message #management.info.git.mode=3Dfull =20 ### # metadata-providers.xml write configuration =20 # Set the following property to periodically write out metadata providers c= onfiguration. There is no default value; the following is just an example # The run rate is defined in milliseconds. You will need to configure your = Shibboleth IDP to read the produced file # shibui.metadataProviders.target=3Dfile:/opt/shibboleth-idp/conf/shibui-me= tadata-providers.xml # shibui.metadataProviders.taskRunRate=3D30000 =20 # Email configuration (local mailhog) # spring.mail.host=3Dmailhog # spring.mail.port=3D1025 # spring.mail.username=3Dusername # spring.mail.password=3Dpassword # spring.mail.properties.mail.smtp.auth=3Dfalse # spring.mail.properties.mail.smtp.starttls.enable=3Dfalse =20 shibui.mail.text-email-template-path-prefix=3D/mail/text/ shibui.mail.html.email-template-path-prefix=3D/mail/html/ shibui.mail.system-email-address=3DdoNotReply@shibui.org =20 =20 #ShibUIConfiguration slurps in these values and they are bootstrapped in on= startup shibui.roles=3DROLE_ADMIN,ROLE_ENABLE,ROLE_USER,ROLE_NONE #Authenticated access roles - used by Spring Security to allow access when = authenticated shibui.roles.authenticated=3DADMIN,ENABLE,USER =20 #In order to enable authentication via configured pac4j library (with exter= nal SAMl Idp, for example) #This property must be set to true and pac4j properties configured. For sam= ple pac4j properties, see application.yml #for an example pac4j configuration #shibui.pac4j-enabled=3Dtrue =20 #This property must be set to true in order to enable posting stats to beac= on endpoint. Furthermore, appropriate #environment variables must be set for beacon publisher to be used (the one= s that are set when running shib-ui in #docker container shibui.beacon-enabled=3Dtrue
The following properties may be= customized through an `application.yml` file.
Example:
Attribute Release
|
name: The name of the entry. used to uniquely iden= tify this entry.
displayName: This will normally be the label used = when displaying this override in the UI. (set in messages.properties)
Note: The application.yml
file allows you to create Relying=
Party overrides that will be imported into the database configuration at s=
tartup. This can be used to bootstrap the database with a set of Relying Pa=
rty overrides. Once the Shibb UI has imported these overrides, they will be=
managed through the user interface (as Custom Attributes) and any changes =
to them in the application.yml
file will be ignored in favor o=
f the configuration in the database. Adding overrides to the applicat=
ion.yml
file is not recommended unless you have a large number of ov=
errides to add all at once.
It is imperative when defining these that the "displayType" and "persist= Type" are known types. Typos or unsupported values here will result in that= override being skipped! Supported types are as follows: boolean, integer, = string, set, list. Note that "persistType" doesn't have to match "displayTy= pe". However, the only unmatching combination currently supported is a "dis= playType" of "boolean" and "persistType" of "string".
Example:
Relying Party Overrides
custom: overrides: - name: signAssertion displayName: label.sign-the-assertion displayType: boolean defaultValue: false helpText: tooltip.sign-assertion attributeName: http://shibboleth.net/ns/profiles/saml2/sso/browser/si= gnAssertions attributeFriendlyName: signAssertions - name: dontSignResponse displayName: label.dont-sign-the-response displayType: boolean defaultValue: false helpText: tooltip.dont-sign-response attributeName: http://shibboleth.net/ns/profiles/saml2/sso/browser/si= gnResponses attributeFriendlyName: signResponses invert: true |
name: The name of the entry. used to = uniquely identify this entry.
displayName: This will normally be the label used = when displaying this override in the UI. (set in messages.properties)
displayType: The type to use when displaying this = option
defaultValue(s): One or more values to be displaye= d as default options in the UI
helpText: This is the help-icon hover-over text
attributeName: This is the name of the attribute t= o be used in the xml. This is assumed to be a URI.
attributeFriendlyName: This is the friendly name a= ssociated with the above attributeName.
invert:
persistType: Optional. If it is necessary to persist so= mething different than the override's display type, set that type here. For= example, display a boolean, but persist a string.
persistValue: Required only when persistType is us= ed. Defines the value to be persisted.
Note: be sure to read through the Authentication options above, they pro= vide some details that apply regardless of the deployment option you have c= hosen.
We will be using the Docker Testbed environment for this working demo. T=
he Testbed is included in the source project. Please make sure you ha=
ve already deployed the Testbed environment and
verified it is working:
curl -k https://localhost:443/idp/shibboleth= --output <ShibUI Root>/test-compose/shibui/conf/idp_metadata.xml
You will need to stop the Docker containers before continuing in the nex= t section:
docker-compose down
We will be using the Pac4j's library for SAML2 support in ShibUI. This w= ill be easy to implement since ShibUI uses a pluggable architecture.
To enable Pac4j, open and update the following files:
shibui.p= ac4j-enabled=3Dtrue
pac4j-enabled: true
pac4j:=
keystorePath: "/etc/opt/samlKeystore.jks"
 = ; keystorePassword: "changeit"
privateKeyPassword: "change= it"
serviceProviderEntityId: "https://idp.example= .com/shibui"
serviceProviderMetadataPath: "/etc/opt/sp= -metadata.xml"
identityProviderMetadataPath: "/etc/opt/idp= -metadata.xml"
forceServiceProviderMetadataGeneration: fal= se
callbackUrl: "https://localhost:8443/callback= "
maximumAuthenticationLifetime: 3600000
s= impleProfileMapping:
username: urn:oid:0.9.2342.192= 00300.100.1.1
firstname: urn:oid:2.5.4.42
= lastname: urn:oid:2.5.4.4
email: urn= :oid:0.9.2342.19200300.100.1.3
Make sure the keystore file, idp metadata file, and both application fil= es are moved to the ShibUI container when started:
- ./shibui/conf/application.yml:/opt/shibui/= application.yml
- ./shibui/conf/samlKeystore.jks:/opt/shibui/samlKeystor= e.jks
- ./shibui/conf/application.properties:/opt/shibui/application.pro= perties
- ./shibui/conf/idp-metadata.xml:/opt/shibui/idp-metadata.xml
Now run Docker:
docker-compose up
When the Docker containers are running, you will need to log into the Sh= ibUI container and copy the newly created sp-metadata.xml file to a new&nbs= p;test-compose/idp/container-files/services/sp-metadata.xml&= nbsp;file.
Once this is complete, add the following to the te= st-compose/idp/Dockerfile:
COPY container-files/services/sp-metadata.xml /opt/shibbolet= h-idp/metadata/sp-metadata.xml
At this point you will need to add the ShibUI application as a new SP to=
Shibboleth IdP. The files you will need to update are located at
The following suggested setup will allow you to configure the generation= of configuration from the ShibUI to be ingested for use in your Shibboleth= IDP with the minimal amount of effort.
example
|
Shibboleth will require a restart to pick up the change.
Once ShibUI is up and running, login as an admin user and create a new M= etadata Provider (type: LocalDynamicMetadataResol= ver). Use the shibui.metadata-dir location from step 2 above as th= e directory location.
The dynamic provider will provide Shibboleth with the location of any SP= configured using the ShibUI.
*NOTE: you can use the testbed/integration setup in the project source c= ode to test how this integration works and to see an example of the full en= d-to-end workings of the ShibUi and Shibboleth IDP
Shibboleth Idp UI software includes piece of instrumentation functionali= ty which sends a small batch of statistical data about the environment in w= hich application is deployed such as Docker image name, version, applicatio= n name, etc. to a running "Beacon collector" facility which is exposed as a= REST HTTP endpoint, as defined here: https://spaces.at.internet2.edu/display/TWGH= /TIER+Instrumentation+-+The+TIER+Beacon In the specification page = it is described to be implemented as a external cron job running inside Doc= ker container, which is true for other TAP docker images instrumented with = Beacon, but Shibboleth Idp UI application has this functionality implemente= d as an optional Java module. It is an opt-in type of functionality which i= s off by default but could be turned on with the following application prop= erty:
shibui.beacon-enabled=3Dtrue
Once it is turned on it will assynchronoiusly send beacon data which it wil=
l gather from necessary environment variables (which will be set by TAP Doc=
ker image for shibboleth idp ui application), but if running outside of TAP=
Docker container and those environment variables are not set, even though =
the beacon module is enabled, the data will not be sent. Below is the examp=
le of necessary environment variables that need to be set in order for Beac=
on module to kick in if running outside of TAP Docker container:
LOGPORT=3D"5001"
IMA=
GE=3D"shibui_local_no_image"
MAINTAINER=3D"local_no_mai=
ntainer"
VERSION=3D"1.11.0-SNAPSHOT"
No labels =
a> &nb=
sp; &=
nbsp; =
&nbs=
p; &n=
bsp; =
 =
; &nb=
sp; &=
nbsp; =
&nbs=
p; &n=
bsp; =
 =
; &nb=
sp; &=
nbsp;
Write a comment...