3:48 a.m.
So here's the next question, related to passing
unmodified assertions
from SATOSA to a SP, specifically COmanage and Shibboleth: What's the
right way to bypass the scope checks Shibboleth usually performs on
ePPN/ePTID/ePUID?
I'd like to add that I tried the following:
- removed the Scope element from the SATOSA IdP metadata
- changed the attribute mappings in Shibboleth to use StringAttributeDecoder instead of
ScopedAttributeDecoder
- both of the above together
Shibboleth logs the following:
```
2018-04-09 21:14:07 WARN Shibboleth.AttributeFilter [2]: removed value at position (0) of
attribute (eppn) from (https://proxy-auth.example.com/satosa)
2018-04-09 21:14:07 WARN Shibboleth.AttributeFilter [2]: no values left, removing
attribute (eppn) from (https://proxy-auth.example.com/satosa)
```
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
6:57 a.m.
Hi Matthew,
Why not disable scope checking on the sp side? Or rescope everything to what you have your
proxy issue?
Niels
-------- Oorspronkelijk bericht --------
Van: "Matthew X. Economou" <xenophon at irtnog.org>
Datum: 10-04-18 05:48 (GMT+01:00)
Aan: satosa-users at lists.sunet.se
Onderwerp: Re: [satosa-users] COmanage, Shibboleth, and SATOSA
So here's the next question, related to passing
unmodified assertions
from SATOSA to a SP, specifically COmanage and Shibboleth: What's the
right way to bypass the scope checks Shibboleth usually performs on
ePPN/ePTID/ePUID?
I'd like to add that I tried the following:
- removed the Scope element from the SATOSA IdP metadata
- changed the attribute mappings in Shibboleth to use StringAttributeDecoder instead of
ScopedAttributeDecoder
- both of the above together
Shibboleth logs the following:
```
2018-04-09 21:14:07 WARN Shibboleth.AttributeFilter [2]: removed value at position (0) of
attribute (eppn) from (https://proxy-auth.example.com/satosa)
2018-04-09 21:14:07 WARN Shibboleth.AttributeFilter [2]: no values left, removing
attribute (eppn) from (https://proxy-auth.example.com/satosa)
```
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
_______________________________________________
satosa-users mailing list
satosa-users at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-users
11:50 a.m.
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.
Thanks!
Matthew
--
"The lyf so short, the craft so longe to lerne."
6:37 p.m.
Hi Matthew
On 10-04-18 13:50, Matthew X. Economou wrote:
Niels van Dijk writes:
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
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.
2230
days inactive
2230
days old
3 comments
2 participants
participants (2)
-
niels.vandijk＠surfnet.nl -
xenophon＠irtnog.org