SP metadata for a new "WebAnno SP" in Tübingen

[ccoltekin@gmail.com]

I have just pushed changes with a new SP metadata (for a WebAnno? instance in Tübingen) to the SVN . As I understand, this requires extra coordination for it to be recognized by the IDPs. We do not have a big hurry, but we'd like to make sure that this changes get distributed within a reasonable time frame.

Kind regards,
Cagri Coltekin

[ccoltekin@gmail.com]

This is still not an "emergency", but is it possible to speed up the distribution of this SP metadata to the identity federations?

We would like the service to be used by the CLARIN community without needing to apply for a CLARIN IDP account.

Best regards,
Cagri

[Sander Maijers]

I will do it now.

No agreement was made yet between me and Dieter about the fixed schedule for this work that would start this month, by the way. This is now delayed to next month. Sorry.

[Sander Maijers]

What is the entity ID of the new SP? It is most efficient is that is listed in the ticket already.

[ccoltekin@gmail.com]

Entity ID is "​https://webanno.sfs.uni-tuebingen.de".
Thanks!

[Sander Maijers]

SAML metadata about the SP has appeared in the ​production SAML metadata batch about SPF SPs (around 14:26). DFN-AAI should pick it up from this SAML metadata batch some time today. I have also uploaded the SAML metadata to Belnet. The other identity federations are more involved, I will handle it for those tomorrow.

[Sander Maijers]

Hi Cagri,

DFN-AAI has found that the SAML metadata about your SP is still incomplete. Specifically, they report:

Currently all MDUI elements are missing in the SP metadata, including mdui:PrivacyStatementURL and mdui:InformationURL which are required for assigning the CoCo? and R&S Entity Categories.

Please ascertain that you comply with ​the SAML metadata guidelines. Mind to check and resolve issues in the SAML metadata quality for your SP before and after your commit, as listed in ​this spreadsheet. Finally, always update the SAML metadata template of your SP to make it correspond exactly with the SAML metadata you deposit here (see e.g. ​https://goo.gl/uysudA).

[ccoltekin@gmail.com]

Hi Sander,

Thanks for the pointers. I went through all, and except for descriptions in Finnish (you note that it may be required by the Haka/Kalmar? Union), I think all are fixed now.

The effort also revealed that the existing WebLicht? SP (entityID="​https://weblicht.sfs.uni-tuebingen.de") was also not complying with these rules. I have also updated it. Can you also push the new/modified version of WebLicht? SP metadata? (Again, no big hurry, and I can also create another ticket for this)

I hope all is fine now.

Thanks again!

PS. It might be a good idea to include the utility that produces the spreadsheet at ​https://goo.g/Nl0DCH in the SVN repository, so that SP administrators test metadata after modifying it (of course, if the spreadsheet is created automatically).

[Sander Maijers]

The SAML metadata about the Weblicht SP has some issues still, have you noticed?

The Finnish translations can be made with Google Translate. Either way, I will have to provide them if you want to be registered with Haka, so it is best if they are kept in the SAML metadata. That would be a one-time effort but from them on, I can copy paste the contents in their forms should anything change. I.e., the SAML metadata about our SPs should be as complete as possible so that it is optimally self-contained. Would you mind providing those translations still, so I won't have to amend and commit the SAML metadata myself?

The spreadsheet contents are loaded from the Schematron output produced by ​https://github.com/clarin-eric/SAML_metadata_QA_validator. The Schematron output is available as .svrlt files and as a simplified XML format in the files of which the names end with _qa on ​https://infra.clarin.eu/aai/.

[ccoltekin@gmail.com]

Hi Sander,

Thanks again. Indeed there were some more problems. But the version of metadata at <​https://infra.clarin.eu/aai/prod_md_about_spf_sps.xml> and <​https://infra.clarin.eu/aai/md_about_spf_sps.xml> was not the same as the latest SVN version either.

I have now fixed all issues reported by the QA validator, and committed the changes to the SVN. I have also added descriptions in Finnish, through Google translator. I hope they do not sound too ridiculous.

[Dieter Van Uytvanck]

Hi Cigdem, I noticed this ticket was still open - sorry for this long delay! We have now added the webanno SP to the distribution batch of January 2017.

Then it should get connected to NL, CZ and FI federations.

[André Moreira]

Webanno is till not added to NL.

SURF requires us to run some tests with their staging IdP before propagation into their production system. At the moment this IdP is not accepted by Webanno SP, showing a Tomcat HTTP 403 page.

I have sent an email to the support addresses of webanno requesting that this IdP is temporarily trusted by their SP so we can run the tests. Till this moment I received no answer.

Another problem found by SURF is that the SSL certificate of the ​ACS URL is missing some intermediate certificates. Please see ​SSLlabs

[ccoltekin@gmail.com]

Thank you for looking into this.

Do you have any pointers on what/how to allow for SURF staging IdP? (I do not want change the configuration based on guesswork, since I'm afraid of the consequences of my lack of fluency on shibboleth).

Ignore this if I'm getting this all wrong, but should this IdP be listed in <​https://infra.clarin.eu/aai/prod_md_about_spf_idps.xml>, <​https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml> or some other standard place if it is useful for all SPs?

The SSL issue should be resolved now.

[André Moreira]

Thank you for solving the SSL issue.

The SURF staging IdP is a publicly available IdP with many preset accounts. These accounts have publicly listed ​credentials so we do not want to include it permanently in any of our feeds.

This said, I actually ran a test where I included this IdP in our feed. As a consequence, the Webanno SP started trusting the SURF's staging IdP and login could go trough.
However as mentioned before, I then hit a Tomcat HTTP 403 page. This suggests that there is some user filtering at the application level. Is this the case?

So to allow SURFs IdP on webanno you will have to temporarily import/add the ​SURF's IdP metadata to you SP. How to do this is very specific to your deployment. Perhaps this can help:

​https://cdn.rawgit.com/clarin-eric/SPF-tutorial/master/Shib_SP_tutorial.html#_specifying_spf_idps
​https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAddIdP
​https://www.clarin.eu/content/creating-and-testing-shibboleth-sp

Please let me know if you need further assistance.
You can also talk with us on the CLARIN-ERIC SPF slack channel, please let me know if you would like to join.

[ccoltekin@gmail.com]

Thank you for the help & pointers.

I think I also found the 403 problem. We had some scoping filters not allowing IdP to use eppn, targettedID etc. coming from different scopes, while SURF staging IdP uses many different domains/scopes for these attributes. For now, I disabled these filters, which seems to allow all SURF staging IdP users. I guess on the long run we can again re-enable these filters as it is unlikely for real IdPs? to issue ID's outside their scope.

This I think resolves the issues.
Please let me know if there is anything further to be done on our side.

Thanks again for all the help.

[André Moreira]

You are welcome!
We are setting up a new instance of our discovery service which includes all the regular IdPs plus the SURF staging one.
The idea is to bring this instance online whenever an SP needs to be tested on SURF's staging environment and then shut it down again when done. This way we will not affect neither the other CLARIN SPs, nor people who are trying to access the staging (for SURF) SP from any other federation than SURF.

This is still not ready but after it is, we will ask you to temporarily switch your discovery service URL to this instance. Then, we will run some tests and after we finish, you will be able to switch the URL back to the regular one.

I will come back to this issue when we are ready.

[André Moreira]

OK, it's ready!

Can you repoint the discovery service URL of the Webanno's SP to: ​https://test-discovery.clarin.eu/discojuice

For Shibboleth, change in shibboleth2.xml:
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.clarin.eu/discojuice">
to
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://test-discovery.clarin.eu/discojuice">

let us know when done.

[ccoltekin@gmail.com]

Test-discovery is configured, and it seems to work for me.

Please let me know when to roll back to the normal configuration.

[André Moreira]

Thank you very much. I also ran some tests without any issues.

I have just requested that SURF propagates the SP to their production system. I don't expect any problem in the process but I will just close this ticket when I receive their confirmation.

Meanwhile you can already roll back your configuration for both the discoveryURL as well as the application scoping filters you had in place.

A different issue: I previously tried to contact the person responsible for this SP about this issue.
First, I used the email address ​wladmin@sfs.uni-tuebingen.de as displayed in the ​SP's metadata. Then I tried Marie Hinrichs as displayed in the ​centre registry but I never got an answer. Are you also beind ​​wladmin@sfs.uni-tuebingen.de? Otherwise may I suggest the technical contact is updated?

[ccoltekin@gmail.com]

Thank you for looking into this issue - and for helpful tips.

I am not behind the address, but the ​wladmin@sfs.uni-tuebingen.de email address is correct, and Marie is also the right contact person. She had been away until late last week, and I already informed her that I am looking at this issue. Probably this is the reason for slow/no response (and likely the large number of emails to sort and react after her absence).

[André Moreira]

That's understandable. It's all good then.

[André Moreira]

Webanno is now added to SURFconext production environment. All changes can be rolled back:

1. discoveryURL can be set back to:

<SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.clarin.eu/discojuice">

2. Application scoping filters can be re-enabled.

Closing ticket.