[JIRA] Commented: (EDS-31) Allow the EDS to be configured to honour the UK federation <wayf:HideFromWAYF> element.
Rod Widdowson (JIRA)
noreply at shibboleth.net
Mon Nov 21 18:42:25 GMT 2011
[ https://issues.shibboleth.net/jira/browse/EDS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715#comment-13715 ]
Rod Widdowson commented on EDS-31:
----------------------------------
As background, the UK Metadata carries this Extension for IdPs which are under test. By default the UK CDS hides these IdPs - there is separate CDS page where all IdPs can be tested. That way all IdPs can be in the production metadata, but the usual user only sees production ready ones.
Whilst we do not want to integrate the UK processes, I am very happy to consider ways of helping the white/black listing over and above that offered by the SP, since the above example does generalize; remember an excluded IdP *will* still be visible to the SP, so whitelisting at the SP <MetadataProvider/> level doesn't have the same effect.
So as I see it, the overarching requirement here is to allow the content of the metadata to affect the JSON feed. In the UK case it is an extension, the actual requirement is liable to be something which can be standardized (like an attribute). Of course the real problem comes when metadata collides and we may need to have different ways of indicating "this is to be suppressed". Certainly as far as I can guess the future, the choice of what is to be suppressed and what is going to have to be a per SP decision.
There is currently ongoing discussion about the best way to drive this. It is complicated in that there are two parties involved, the one generating the JSON and the one consuming it.
>From the EDS point of view there are three techniques:
1) "It's All Scott's problem". Punt the solution to the SP. I'm not sure that this really holds water. How on earth can we configure the SP to do blacklisting based on arbitrary content, and all to feed the DS.
2) Add some info into the JSON Schema which the SP can pass along. We can then add configuration to the EDS to "do something sensible". This has much of the same issues as the above, with the possible difference that we are already in a scripting language and people can be arbitrarily baroque in that.
3) Just teach the EDS to (optionally) listen to second JSON feed, being the black list (which can be dynamic or static).
The last is somewhat kludgy, but I like this solution the most since it takes the actual decision about what to blacklist out of the control of EDS or SP configuration. A way of achieving the Initial request would be for the UK Federation to issue a suitable JSON feed every night alongside the metadata feed. No Tonto we are not going to collect it via JSONP; an SP that cared could set up a cron script to wget it. Of course the cron script will fail and the SP will get out of date, much as SPs WAYF metadata gets out of date now. I suppose we could add a validUntil attribute into the blacklist schema if we thought this mattered (which I happen to).
If we ever get to the stage whereby attributes to suppress IdPs from visibility become standard and adopted, we can roll the generation of this data into the SP code. But that can be done as an orthogonal operation.
> Allow the EDS to be configured to honour the UK federation <wayf:HideFromWAYF> element.
> ---------------------------------------------------------------------------------------
>
> Key: EDS-31
> URL: https://issues.shibboleth.net/jira/browse/EDS-31
> Project: Embedded Discovery Service
> Issue Type: New Feature
> Reporter: nzuvrwq4kbe5j7ftsnc4oe8fnkq=@https://idp.ed.ac.uk/shibboleth
> Assignee: Rod Widdowson
>
> Allow the EDS to be configured to honour the UK federation <wayf:HideFromWAYF> element, which directs the DS not to display any IdPs containing that element.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the commits
mailing list