Add lookup strategy for populating Address attributes
Description
Environment
Activity
Scott Cantor December 19, 2019 at 2:07 AM
If shibboleth.SubjectLocalityAddressStrategy is defined, will be called to return the String to populate, or null to omit SubjectLocality.
Scott Cantor July 30, 2019 at 12:03 PM
I'd say so. It sounds like there's a system property (org.eclipse.jetty.util.HostPort.STRIP_IPV6) to fix the problem (which is itself apparently specific to proxying and address header forwarding) and that they're planning to default to stripping them in 10.
I would say that as a "current" issue, this doesn't really look like our issue to fix, and the workaround already exists.
But there have already been occasional requests for remapping options so having a lookup function setting isn't a bad RFE anyway. But this doesn't look like a bug.
Aaron Howell July 30, 2019 at 10:52 AM
Thanks for that.
We have Jetty 9.4 (we have specifically 9.4.11).
It might be something to do with this - https://github.com/eclipse/jetty.project/issues/1503 - although they loose me towards the end with what they actually patched.
Scott Cantor July 29, 2019 at 3:56 PM
My SP of course just does direct compares, so I'm not really sure but it seems as though "most" deployments must surface this without the brackets, or at least whatever they do, it either matches Apache or people have just long since stopped enabling the check. It is in fact off by default in the SP now, has been for a long time.
The problem I have is simple: no Ipv6 access of any sort anywhere, so I have no way to test this in terms of exploring the scenarios.
I think we may want to just go all the way and add a plugin hook to establish the address to populate and then people can script away. That just avoids all the assumptions and opens up other featured that have been asked for, such as remapping.
Rod Widdowson July 29, 2019 at 3:49 PM
That value is coming directly from the servlet, so it would be extra-ordinarily useful to know what container (tomcat/jetty) you are using.
This reply on StackOverflow seems to indicate that the value MUST be as per RFC 3513
So there is definitely a bug, but it may not be ours.. (I went looking for arrays and found none)
We have had reports of from an SP where some users are being blocked and they have informed us that there is an issue with the SAML token from our IdP.
To quote them:
This seems to be because you are sending the wrong format of saml to us: SubjectConfirmationData Address="[2001:db8:5496:9100:588a:5192:c74:d5c5]"
This would work if the number was not placed in brackets. a working example would be:Address="2001:db8:5496:9100:588a:5192:c74:d5c5"
The exact error on this one is "Not an IPv4 or IPv6 address"
I have looked at what I think is the SAML spec for this: http://docs.oasis-open.org/security/saml/Post2.0/saml-session-token/v1.0/csd01/saml-session-token-v1.0-csd01.html
Which states "Address [Required] The SA MUST set the value of the saml:Address attribute to contain the address of the browser in IPv4 dotted decimal format, e.g. "198.51.100.1" or in IPv6 address format as described in Section 2.2 of [RFC3513], e.g.,"2001:db8::1". The SC MAY compare the value to the known address of the browser."
RFC3513 does not appear to have anything about the square bracket syntax - so while I think they should be coping with this format (as I have to presume many others are) - I don't currently appear to have a lot of ground on to push back on - and I haven't found a way to configure Shibboleth to behave differently.
(as sent to the the mailing list)