Hi Matthew
On 10-04-18 13:50, Matthew X. Economou wrote:
Niels van Dijk writes:
Why not disable scope checking on the sp side?
I thought I did that, but after reading through the Shibboleth wiki last
night, I think my attribute extractor config in Shibboleth is wrong.
I'm going to remove the AttributeDecoder statements entirely and see
what that gets me.
Or rescope everything to what you have your proxy
issue?
The proxy isn't issuing anything for COmanage - it passes the IdP's
assertions unchanged for registration purposes. I will properly scope
the VO identifier for my other SPs, because that lets me use the default
Shibboleth configuration.
An SP typically expects 1 IdP to deliver only 1 (or a small set of)
scopes. When using a proxy there are typically 3 ways around this:
- make your SP ignore the scopes. Technically doable, but only if the SP
is totally under your control. If the SP also needs to engage with
others IdP(proxies) it will probably not want to do this.
- Make the proxy rescope all original attributes, which makes sense in
that the SP must be trusting the proxy anyway, and cannot trust what
lies upstream. This does indeed leave you with an issue if you have to
pass on 'original' identifiers from the IdP. Perhaps these can be
'repackaged' into another attribute? e.g. schacPersonalUniqueID. the
voPerson schema also has some ways for dealing with this.
- Let you proxy publish in its metadata all relevant scopes, which will
make a vanilla Shib SP happy again. However note that that will not go
down well if you would try to publish that IdP proxy metadata in e.g.
eduGAIN as the original owners of the scopes will also be there. So this
will only work in closed environments where the SPs only know about the
IdP proxy.
Best,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org