uApprove.jp (which is an extension of uApprove) is an application which allows an end user to view and to select the attribute set which will be sent to the visiting resource.
This guide describes the installation & configuration of the uApprove.jp for Shibboleth Identity Provider (IdP).
It covers the installation the IdP plugin as well as uApprove.jp viewer application and their configuration with a flat file based or SQL based (Database) storage.
idp.example.org
/opt/uApprove
/opt/uApprove/conf
/opt/shibboleth-identityprovider-2.x
install.sh
lives)/opt/shibboleth-idp
${CATALINA_HOME}
/usr/java/tomcat
).Before start install and configure uApprove.jp, assure that the following prerequisites are met:
Download and unzip the uApprove.jp package:
|
Copy libraries and configuration:
|
Copy libraries and configuration:
|
uApprove.jp consist of two pieces of software, the IdP plugin which runs within the IdP context and the uApprove.jp viewer application which is separated.
Both of them use a common data storage and the according libraries to operate with it.
A file based storage have to be setup in /opt/uApprove/conf/common.properties:
|
Assure that the directory in which |
First, a databases and a user have to be created:
|
Second, generate the table structures:
|
The following table added in uApprove.jp-2.2.1:
The following tables added in uApprove.jp-2.2.1c:
|
For easy checking whether the setting of the database is right, you can use the following command:
|
A Database setup is configured in /opt/uApprove/conf/common.properties:
|
All database specific configuration is done in /opt/uApprove/conf/database.properties:
|
The TermsOfUseManager, which shows a Terms of use text to the user is optional. If the TermsOfUseManager should be active, define the terms in /opt/uApprove/conf/common.properties:
termsOfUse=/opt/uApprove/conf/terms-of-use.xml |
Cause the IdP plugin and the viewer application exchange some confidential information, this is encrypted and decrypted by a shared secret (128 bit, 16 bytes) in /opt/uApprove/conf/common.properties:
|
For easy creating a random value, containing 16 bytes, you can use the following command:
openssl rand -base64 16 2>/dev/null |
The IdP plugin has to be enabled within Shibboleth IdP web application /opt/shibboleth-identityprovider-2.x/src/main/webapp/WEB-INF/web.xml:
|
The |
Redeploy Shibboleth IdP:
|
copy idp.war
into ${CATALINA_HOME}/webapps
:
cp /opt/shibboleth-idp/war/idp.war ${CATALINA_HOME}/webapps/ |
The SP blacklist defines Resources which are excluded from the user consent.
The SP blacklist is optional and can be configured by /opt/uApprove/conf/idp-plugin.properties:
spBlacklist=/opt/uApprove/conf/sp-blacklist |
In sp-blacklist
, each line defines a regular expression pattern for black listed resource identifier:
# Example 1: specific resource https://sp\.example\.org/shibboleth # Example 2: all applications within a Service Provider https://sp\.example\.org/.* # Example 3: all Service Provider within a specific domain https://.*\.example\.org/.* |
uApprove.jp shows all attributes which will be released for the current user to the target resource.
It is possible to define an order of the attribute listing and if necessary, attributes can also be hidden. The configuration of the attribute list is optional done by /opt/uApprove/conf/idp-plugin.properties:
attributeList=/opt/uApprove/conf/attribute-list |
An attribute-list
can be look like:
# Defined attribute order surname givenName postalAddress ... # attributes to hide !persistentId !transientId |
If the database storage is used, it is possible to log each provider access, which means every attribute release is stored in the database.
It is also possible, that the IdP plugin runs in monitoring only mode, which logs every provider access, but do not interact with the user (for user consent)
If the viewer web application is used, the IdP plugin has to know, where it is deployed.
it is possible to tell the IdP plugin, that it should take care about isPassive requests.
The configuration is done in /opt/uApprove/conf/idp-plugin.properties:
logProviderAccess=false |
Define a tomcat deployment descriptor for the uApprove.jp webapp in ${CATALINA_HOME}/conf/Catalina/localhost/uApprove.xml:
<Context docBase="/opt/uApprove/war/uApprove.war" privileged="true" antiResourceLocking="false" antiJARLocking="false" unpackWAR="false" /> |
Adjust the viewer application according you configuration directory in /opt/uApprove/viewer-2.2.1c/webapp/WEB-INF/web.xml:
<web-app> ... <context-param> <param-name>Config</param-name> <param-value> /opt/uApprove/conf/viewer.properties; /opt/uApprove/conf/common.properties; </param-value> </context-param> ... <web-app> |
It is possible to change the logo and the navigation menu. The logo can be used image file in /opt/uApprove/viewer-2.2.1c/webapp/images and/or URL.
The configuration are done in /opt/uApprove/viewer-2.2.1c/webapp/header.jsp:
<body class="switchaai"> <div class="box-aai" style="width: 650px;"> <img src="images/GakuNin_logo.png" alt="GakuNin-logo" class="switchaai" height="32" width="162"> |
Deploy the uApprove.jp webapp:
cd /opt/uApprove/viewer-2.2.1c/ ant deploy -Duapprove.deployment=/opt/uApprove/war |
The viewer web application is multi lingual for the static text and dynamic text, like attribute names and descriptions.
For the static text, the following languages are supported: en, de, fr, it, pt, ja.
For the attribute names and descriptions, the localized content is taken from /opt/shibboleth-idp/conf/attribute-resolver.xml (Shibboleth IdP resolver). It's possible to adjust or extent it:
... <resolver:AttributeDefinition id="postalAddress" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="postalAddress"> <resolver:Dependency ref="myLDAP" /> <resolver:DisplayName xml:lang="en">Business postal address</resolver:DisplayName> <resolver:DisplayName xml:lang="de">Geschäftsadresse</resolver:DisplayName> <resolver:DisplayName xml:lang="fr">Adresse Professionnelle</resolver:DisplayName> <resolver:DisplayName xml:lang="it">Indirizzo professionale</resolver:DisplayName> <resolver:DisplayName xml:lang="ja">所属組織住所</resolver:DisplayName> <resolver:DisplayDescription xml:lang="en">Business postal address: Campus or office address</resolver:DisplayDescription> <resolver:DisplayDescription xml:lang="de">Adresse am Arbeitsplatz</resolver:DisplayDescription> <resolver:DisplayDescription xml:lang="fr">Adresse de l'institut, de l'universite</resolver:DisplayDescription> <resolver:DisplayDescription xml:lang="it">Indirizzo professionale: Indirizzo dell'istituto o dell'ufficio</resolver:DisplayDescription> <resolver:DisplayDescription xml:lang="ja">所属組織(大学、会社など)の住所</resolver:DisplayDescription> <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:mace:dir:attribute-def:postalAddress" /> <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid:2.5.4.16" friendlyName="postalAddress" /> </resolver:AttributeDefinition> ... |
It is possible that a user can give global attribute release consent, which mean, that she/he is never be asked again by uApprove.jp. If it is required, that a user has to give consent to each different resource access, global consent has to be disabled in /opt/uApprove/conf/viewer.properties:
globalConsentPossible=true |
The viewer web application uses LogBack (see 1.7 References) like the Shibboleth IdP.
The logback configuration file is defined in /opt/uApprove/conf/viewer.properties:
loggingConfig=/opt/uApprove/conf/logging.xml |
Adjust logging.xml
for the log location, assure that the file is writable by Tomcat:
<configuration> ... <appender class="ch.qos.logback.core.FileAppender" name="RootFileAppender"> <file>/opt/uApprove/logs/uApprove.log</file> ... </appender> ... </configuration> |
If you are using Apache HTTPd in front of your Tomcat setup, proxy the viewer web application in /etc/httpd/conf.d/ssl.conf :
<VirtualHost idp.example.org:443> ... <Location /uApprove> Allow from all ProxyPass ajp://localhost:8009/uApprove </Location> ... </VirtualHost> |
Restart Apache HTTPd:
/sbin/service httpd restart |
uApprove.jp generates the list of attributes depending on the user consent in the Attribute Query SAML Response message.
In you profile handler file (e.g. /opt/shibboleth-idp/conf/handler.xml) you'll need to add the namespace declaration for this plugin. To do this:
Add the attribute xmlns:uajpph="http://www.gakunin.jp/ns/uapprove-jp/profile-handler"
before the xmlns:xsi
attribute on the root <ProfileHandlerGroup>
element.
Add the following at the end of the whitespace delimited list of values for the xsi:schemaLocation
attribute: http://www.gakunin.jp/ns/uapprove-jp/profile-handler classpath:/schema/shibboleth-2.0-idp-profile-handler-uapprovejp.xsd
|
You'll change the Attribute Query profile handlers. To do this:
change the value of xsi:type
from ph:SAML1AttributeQuery
to uajpph:SAML1AttributeQueryUApprove
change the value of xsi:type
from ph:SAML2AttributeQuery
to uajpph:SAML2AttributeQueryUApprove
|
uApprove.jp determines whether an attribute is mandatory or optional by recognizing <RequestedAttribute>
elements in metadata of an SP (see 2. Configuration of Shibboleth Service Provider) and <AttributeFilterPolicy>
elements in attribute filter policy file of the IdP.
In you attribute filter policy file (e.g. /opt/shibboleth-idp/conf/attribute-filter.xml) you'll need to add the namespace declaration for this plugin. To do this:
Add the attribute xmlns:uajpmf="http://www.gakunin.jp/ns/uapprove-jp/afp/mf"
before the xmlns:xsi
attribute on the root <AttributeFilterPolicyGroup>
element.
Add the following at the end of the whitespace delimited list of values for the xsi:schemaLocation
attribute: http://www.gakunin.jp/ns/uapprove-jp/afp/mf classpath:/schema/shibboleth-2.0-afp-mf-uapprovejp.xsd
|
uApprove.jp-2.2.1a or later, the namespace URI has been changed.
|
uApprove.jp enhances Policy Requirement Rule and Permit/Deny Value Rule in Attribute Rules:
<afp:PolicyRequirementRule xsi:type="uajpmf:AttributeUapprove">
element and is applied when <AttributeConsumingService>
elements exist in metadata of an SP.<afp:PermitValueRule xsi:type="uajpmf:AttributeUapprove"/>
elements and <afp:DenyValueRule xsi:type="uajpmf:AttributeUapprove"/>
elements with the following optional attributes:isRequired
attribute of <RequestedAtrribute>
elements within <AttributeConsumingService>
elements in metadata of SP is true, this attribute is the mandatory attribute and is always released to an SP.Boolean flag indicated that only this attribute which is defined in metadata of an SP should be displayed,
Default value: false
The permitted attributes without xsi:type="uajpmf:AttributeUapprove"
are handled as the mandatory attributes.
Example Permit Value Rule using the uajpmf:AttributeUapprove Match Function:
<!-- ================================================================================== case 1: match SPs that has some AttributeConsumingService elements in metadata. The eduPersonPrincipalName attribute is the optional attribute and the end user can select whether to release. The eduPersonAffiliation attribute is the mandatory attribute and is always released. ================================================================================== --> <afp:AttributeFilterPolicy id="PolicyforSPwithAttributeConsumingService"> <afp:PolicyRequirementRule xsi:type="uajpmf:AttributeUapprove" /> <afp:AttributeRule attributeID="eduPersonPrincipalName"> <afp:PermitValueRule xsi:type="uajpmf:AttributeUapprove" /> </afp:AttributeRule> <afp:AttributeRule attributeID="eduPersonAffiliation"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> ... </afp:AttributeFilterPolicy> <!-- ================================================================================== case 2: match SPs that doesn't have any AttributeConsumingService elements in metadata. The eduPersonPrincipalName attribute and the eduPersonAffiliation attribute are the mandatory attributes. ================================================================================== --> <afp:AttributeFilterPolicy id="PolicyforSPwithoutAttributeConsumingService"> <afp:PolicyRequirementRule xsi:type="basic:NOT"> <basic:Rule xsi:type="uajpmf:AttributeUapprove"/> </afp:PolicyRequirementRule> <afp:AttributeRule attributeID="eduPersonPrincipalName"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> <afp:AttributeRule attributeID="eduPersonAffiliation"> <afp:PermitValueRule xsi:type="basic:ANY" /> </afp:AttributeRule> ... </afp:AttributeFilterPolicy> <!-- ================================================================================== case 3: match all SPs. The eduPersonPrincipalName attribute and the eduPersonAffiliation attribute are the optional attributes. ================================================================================== --> <afp:AttributeFilterPolicy id="PolicyforAnyone"> <afp:PolicyRequirementRule xsi:type="basic:ANY" /> <afp:AttributeRule attributeID="eduPersonPrincipalName"> <afp:PermitValueRule xsi:type="uajpmf:AttributeUapprove" /> </afp:AttributeRule> <afp:AttributeRule attributeID="eduPersonAffiliation"> <afp:PermitValueRule xsi:type="uajpmf:AttributeUapprove" /> </afp:AttributeRule> ... </afp:AttributeFilterPolicy> |
Do not use this configuration if you use list-approvals application. |
The optional reset-approvals can be operated in two ways:
For enabling the In-Flow reset-approvals application, the Shibboleth UsernamePassword login form ${CATALINA_HOME}/webapps/idp/login.jsp can be adapted by adding a checkbox:
|
For the standalone mode, the JSP has to be protected either by container managed authentication or Shibboleth Service Provider, that the REMOTE_USER
is provided.
The standalone JSP can be called like https://idp.example.org/uApprove/reset-approvals.jsp?standalone-next-url=http://go.here.org/after/reset
. The parameter standalone-next-url
has to be set.
Do not use this configuration if you use reset-approvals application. Please delete the settings in the previous version. |
For the standalone mode, the JSP has to be protected either by Shibboleth Service Provider, that the REMOTE_USER
is provided.
Install and setup Shibboleth SP on IdP host. The metadata exchange with the IdP, and configure the SP to transition to IdP directly IdP without through the DS when execute Shibboleth authentication.
Add uid to REMOTE_USER in /etc/shibboleth/shibboleth2.xml.
<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. --> <ApplicationDefaults entityID="https://idp.example.jp/shibboleth" REMOTE_USER="uid eppn persistent-id targeted-id"> |
Add attribute definition of uid in /etc/shibboleth/attribute-map.xml.
<Attribute name="urn:mace:dir:attribute-def:uid" id="uid"/> <Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="uid"/> |
Define uid in /opt/shibboleth-idp/conf/attribute-resolver.xml.
Define Policy Requirement Rule to allow only uid to /opt/shibboleth-idp/conf/attribute-filter.xml.
Add the following definition to /etc/httpd/conf.d/ssl.conf.
... <LocationMatch /uApprove/list-approvals.jsp> AuthType shibboleth ShibRequestSetting requireSession 1 require valid-user </LocationMatch> ... |
The JSP can be called like:
https://idp.example.org/uApprove/list-approvals.jsp
Restart Tomcat:
/sbin/service tomcat6 stop && sleep 10 && /sbin/service tomcat6 start |
Check the logs, if the startup of the IdP and uApprove.jp web application was successful. |
Cause the IdP plugin runs within the Shibboleth IdP web application, it uses the IdP logger. The IdP logger is configured by /opt/shibboleth-idp/conf/logging.xml:
... <logger name="ch.SWITCH.aai" level="DEBUG"> |
The logging of uApprove.jp viewer application is configured as described. Adjust the log level to DEBUG
.
uApprove.jp is shipped for a JDK 1.5 target. However your Tomcat setup runs with a JDK ≥ 1.5, it could be that the Jasper engine compiles the JSP's on the fly for another target (e.g. 1.3). The following configuration in ${CATALINA_HOME}/conf/web.xml specifies for which target the JSP's has to be compiled:
<servlet> ... <init-param> <param-name>compilerSourceVM</param-name> <param-value>1.5</param-value> </init-param> <init-param> <param-name>compilerTargetVM</param-name> <param-value>1.5</param-value> </init-param> ... </servlet> |
An SP can define the attributes that the SP requires or desires using <RequestedAttribute>
elements within <AttributeConsumingService>
elements within <SPSSODescriptor>
element. The <RequestedAttribute>
element have the following attributes:
isRequired (optional)
Can be described the description of attribute by adding a following attribute to the <RequestedAttribute>
element. The described description is displayed in Attribute Selection Page by the viewer application of uApprove.jp.
Using a <uajpmd:RequestedAttributeExtension>
element can provide the description by multiple language. The descriptions defined by <uajpmd:RequestedAttributeExtension>
element takes precedence over the descrived one by the uajpmd:description
attribuite. The <uajpmd:RequestedAttributeExtension>
element must be contained within the <Extensions>
element that is a chiled of <SPSSODescriptor>
element.
The <uajpmd:RequestedAttributeExtension>
element must have the following attibutes:
FriendlyName
atttibute of the <RequestedAttribute>
element to associate this element.
The description of attribute is described in the <uajpmd:Description>
element. The <uajpmd:RequestedAttributeExtension>
element can be contain one or more <uajpmd:Description>
elements.
The <uajpmd:Description>
element must have the following attibutes:
Example:
|