Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 5 Nächste Version anzeigen »

Testing authentication

Provided you already have completed your metadata configuration by follwing our instructions you can test your authentication configuration with a web browser using IDP-initiated SSO URLs. While the details for this (as always) are fully documented in the Shibboleth Wiki it should suffice to know that the URL needs to look like this:

https://YOUR-PUBLIC-IDP-HOSTNAME/idp/profile/SAML2/Unsolicited/SSO?providerId=https://test-sp.aco.net/shibboleth

Where "YOUR-PUBLIC-IDP-HOSTNAME" above needs to be replaced with just that, e.g. "weblogin.example.edu". This should then create a Shibboleth IDP-specific authentication request to your IDP which then should lead to your IDP's login page being displayed. Entering correct (and also incorrect) credentials can then be used to determine whether authentication works as desired.

Failure at SAML SP expected!

Until your IDP is known to SPs via metadata (commonly by having your IDP's metadata registered within eduID.at) you'll end up at the SP – in the above example that's the entityID of the eduID.at SAML Demo SP – with an error message of some kind, letting you know that it doesn't know your IDP. That's fully expected before your IDP has joined eduID.at and does not limit your ability to test/verify your IDP's authentication configuration.

Testing the attribute resolver and filter

Command Line Interface

Provided you already have completed our metadata configuration instructions you can test both your attribute resolver and attribute release from the command line, without the need for a "Test SP" that shows you what it recieved and without having to use a web browser. This greatly accelerates configuration (verification) of your IDP so do make use of this before and after any change.

The official documentation of course has all the details, but mostly all you need is to run the following command on our IDP server:

/opt/shibboleth-idp/bin/aacli.sh --saml2 -n SOME_USERID -r https://test-sp.aco.net/shibboleth

Where "SOME_USERID" above needs to be replaced with the userid/login name people would enter as part of authenticating to your IDP. Then the attributes, their values as well as any NameIDs that would be sent to the SP identified by its entityID – in the above example that would be the eduID.at AML Demo SP – will be shown, in XML the way it would be sent in a SAML Assertion (after encrypting and encoding the data to the SP named as recipient, of course).

Note that no data is sent anywhere using that method, this command simply provides an answer to the question "What attributes (and NameIDs) – if any – would the IDP send for account X to service Y using the current configuration?"

Test Service Provider

ACOnet also operates the eduID.at Demo SP for full end-to-end testing involving you web browser, authentication, attribute lookup and filtering, signing (and signature verification, at the SP) encryption (and decryption, at the SP), etc. While this SAML SP knows all eduID.at IDPs the ACOnet Team can also add your IDP's metadata to the Demo SP locally, in order to faciltate end-to-end testing before your IDP has been registered in eduID.at.

You'll need to send a copy of your IDP's metadata (a basic version thereof has been created by the Shibboleth IDP's installer in /opt/shibboleth-idp/metadata/idp-metadata.xml) to the ACOnet Team.  In turn the ACOnet Team will provide you with a URL you'll need to use to initiate SSO with your IDP.

The URL you'll be recieving from the ACOnet Team will look like this:

https://sp.eduid.at/Shibboleth.sso/Login?entityID=YOUR-IDP-ENTITY-ID

Where "YOUR-IDP-ENTITY-ID" above needs to be replaced with the entityID of your IDP.

  • Keine Stichwörter