Skip to Content.
Sympa Menu

edugain-discuss - [eduGAIN-discuss] Tool to monitor which IdP consumes your SP's metadata

edugain-discuss AT lists.geant.org

Subject: An open discussion list for topics related to the eduGAIN interfederation service.

List archive

[eduGAIN-discuss] Tool to monitor which IdP consumes your SP's metadata


Chronological Thread 
  • From: Mikael Linden <mikael.linden AT csc.fi>
  • To: <edugain-discuss AT geant.net>
  • Cc: jmisutka AT gmail.com
  • Subject: [eduGAIN-discuss] Tool to monitor which IdP consumes your SP's metadata
  • Date: Fri, 27 Jun 2014 16:46:50 +0300 (EEST)
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>

Dear eduGAIN-discuss,

 

One of the issues in eduGAIN is that an SP admin does not know which IdPs actually consume the SP’s metadata. The SP admin may not want to show an IdP in the Discovery Service if the IdP would just present a nasty error message to the end user.

 

Jozef Misutka of Charles University in Czech republic has implemented a tool which takes (eduGAIN) SAML2 metadata, browses through the IdPs and gives a try for each of them. See  Jozef’s mail below. The tool has been implemented for the CLARIN community and is available in:

https://lindat.mff.cuni.cz/secure/aai-idps-weblicht

 

I wonder if this tool is interesting for the eduGAIN community in general, and if it could be provided/supported as part of the eduGAIN service.

 

Cheers,

mikael

 

From: jmisutka AT gmail.com [mailto:jmisutka AT gmail.com] On Behalf Of Jozef Misutka
Sent: 10. June 2014 16:57

 

Every SP regards a set of IdPs as trustworthy (e.g., based on the metadata provider feeds it harvests) and functional. Each of these IdPs should offer a login screen when redirected from the SP. The redirection is (usually?) done with a dedicated SP url controlled by a parameter specifying the entityID of the IdP. 

However, we have found out that the trust is not always mutual and that some of the IdPs do not work as expected.

 

However, if you obtain the list of IdPs and the redirection URL you can automatically visit the login screen and verify few things:

 

1) the IdP is up and running (check the connection, http error codes);

2) the IdP also regards the SP as trustworthy (means that the SP information was inside one of the metadata provider feeds the IdP harvests, usually you see "message did not meet security requirements");

3) there is no internal error and/or similar (there are magic strings which we look for like unhandledexc, error processing request, ... based on our previous experience)

 

I have tested four different SPs and the results can be seen for each of them. Please note the date when the scan was performed.

 

After heartbleed and the newest openssl problems, we do not want to terrify people (again) with scanning their IdPs so I disabled automatic scans.

 

Best,

Jozef




Archive powered by MHonArc 2.6.19.

Top of Page