Functional Tests for Service Providers

The DFN operates two IdPs for performing functional tests in the Test Federation:

DisplayName EntityID Remarks
DFN Test-IdP 2 SAML2, standard behaviour (attribute push)

NB: There is also an AAI Integration and Test IdP available in the production federation. Accounts are issued on request, please contact

The following accounts are available by default:

user password eduPersonEntitlement eduPersonScopedAffiliation description
test-clt test urn:mace:dir:common-lib-terms member@… member of the university
test-na test affiliate@… affiliate with no privileges
test-lwi test urn:mace:dir:common-lib-terms library-walk-in@… walk-in patron at a library terminal
test-me test urn:mace:dir:common-lib-terms; urn:something… member@… member with multiple entitlements
test-ma test urn:mace:dir:common-lib-terms member@… ; staff@… member with multiple affiliations
test-all test only if required in SP metadataonly if required in SP metadataall attributes that the SP requires in its metadata
test-special-characters1, test-special-characters2, test-special-characters3 test only if required in SP metadataonly if required in SP metadatagivenName and sn contain special characters, all attributes that the SP requires in its metadata
test-multi-mail test only if required in SP metadataonly if required in SP metadatamultiple values in e-mail attribute (do not use mail as an identifier, see Best Practice), all attributes that the SP requires in its metadata

The primary purpose of these accounts is to test authorisation with typical content providers - in this case the user 'test-na' is not entitled to access any protected content.

If more and/or other attributes are required to access and use a specific Service, please contact Further test accounts are available on request.

Important: At many Home Organizations (not only in Germany), there are also users registered with the Identity Management System (and therefore able to login to the IdP) that are not members of the respective Institution in a strict sense, like guests, cooperation partners, almuni etc.
In the overwhelming majority of cases, a service (respectively a Service Provider) is supposed to be available only for a subset of the users affiliated with a Home Organization. For this reason, a successful authentication at the home IdP is usually not sufficient for granting access to a protected resource! Rather, the authorization decision must be made by means of the user attributes released by the IdP. Which attributes (and attribute values) are appropriate for this purpose, depends on the type and implementation of the service / Service Provider. If you have any questions, please contact the DFN-AAI Helpdesk.

See also the comprehensive documentation on implementing access control with Shibboleth SP provided by SWITCHaai.

Next step: Production Environment

  • Last modified: 4 months ago