This microservice is a stub IDP that can be white-labelled to simulate any IDP, or used as a Stub eIDAS Proxy Service Node.
Commits made up to and including 83a97b5157c25f3dad56bc0293ef5e78d8a2b2a4 in this repository may have had their history altered as part of the open sourcing process. That means the apparent changesets are incomplete due to removed files, and thus the commit messages could not be representative of the changes made at the time.
Merge commits were not preserved as part of the open sourcing process.
Use verify-local-startup to start the app. It will also create all the appropriate config/PKI to run the app locally.
A yaml file containing IDPs needs to be created and the file location set as stubIdpsYmlFileLocation in the app yml config file
The format is as follows:
stubIdps:
- friendlyId: stub-idp-one-for-rp1
displayName: Stub IDP One
assetId: stub-idp-one
sendKeyInfo: true
idpUserCredentials:
- user: userName
password: <password hash>The friendlyId can be used to enable multiple IDPs but using the same displayName and assetId e.g. for different on-boarding relying parties.
Header images for IDPs should be placed into ida-stub-idp/src/main/resources/assets/images/providers/ and are referenced as assetId e.g. stub-idp-one.png is referenced as stub-idp-one
## Deploying to PaaS
Before Stub IDP can be deployed to PaaS, you need to provision two services in the space you are deploying to. Make sure you are logged into PaaS Cloudfoundry and then run ./create_paas_services.sh as follows:
CF_SPACE=target-space LOGIT_ENDPOINT=endpoint ./create_paas_services.sh
The Logit endpoint can be obtained by logging into logit.io (via GApps) and copying the Verify Stubs stack ID.
You need to use the entityId http://stub_idp.acme.org/{friendlyId}/SSO/POST or as the template configured in the main config file, with the shared key/cert configured in the main config file (stub-idp.yml)
The SSO URI for that IDP will be http://localhost:50140/{friendlyId}/SAML2/SSO or equivalent.
You need to set the hub (or service) entityId that messages will be received from/sent back to, as well as where the hub/service metadata can be received from -> see the hubEntityId and metadata configuration blocks.
Set the values in europeanIdentity including HUB_CONNECTOR_ENTITY_ID for the consuming relying party/service provider/hub.
Several countries can be dynamically stubbed at once - see the full list in EidasScheme (use the values, not the enum keys). Once the metadata is retrieved for each stub it can be used by the consuming relying party/service provider/hub. Metadata is at http://localhost:50140/[scheme]/ServiceMetadata Test users are all stub-country*.
Test users can be uploaded to the IDPs docs
Basic auth for the /{friendlyId}/users endpoint is enabled by default and can be configured using basicAuthEnabledForUserResource
If you think you have discovered a security issue in this code please email [email protected] with details.
For non-security related bugs and feature requests please raise an issue in the GitHub issue tracker.
Responsible for SAML behaviours which are specific to the domain of IDPs (note that we only stub IDPs internally, hence stub-idp-saml). At a high level:
- Handling requests from Hub
- Generating responses for Hub
At a lower level this includes:
- Converting OpenSAML objects to IDP domain objects
- Converting IDP domain objects to OpenSAML objects
- Generating Matching Dataset Assertions
Common tasks (e.g. validating signatures) are handled by dependencies such as saml-security and saml-serializers.
Currently used by stub idp and compliance tool.
stub-idp-saml-test is provided for services which require IDP-like behaviour to set up state for their tests. For example: in order to test hub we need to generate an example AuthnResponse.
stub-idp-saml-test provides helpful builders for situations like this.
./gradlew clean build
This project is developed under the Alphagov Code of Conduct
This code is provided for informational purposes only and is not yet intended for use outside GOV.UK Verify