That can be arranged...
The attr_filter allows you to use 'Fall-Through', which would mean that your post-proxy and pre-proxy files might look like this:
apc.moonshot.ja.net
GSS-Acceptor-Host-Name =* ANY,
GSS-Acceptor-Realm-Name =* ANY,
GSS-Acceptor-Service-Name =* ANY,
GSS-Acceptor-Service-Specifics =* ANY,
Fall-Through = Yes
So it could be commented out and enabled only for realms you know are on the trust router. Any other domains that you need to include the attributes in would need to be listed in a similar fashion.
But I'll be able to experiment with that a little bit more soon.
Stefan
-----Original Message-----
From: Sam Hartman [mailto:[log in to unmask]]
Sent: 07 July 2014 13:07
To: Stefan Paetow
Cc: [log in to unmask]
Subject: Re: attr_filter in FreeRADIUS + GSS-Acceptor-* attributes
Here, I think we need to consider the boundary between what we ship with freeradius and what we ask people to configure.
I don't know where that boundary should be but it kind of matters for this.
If you are going to pass along gss-acceptor-host-name, you need to verify that it's correct for a client (if you are a proxy near the
client)
If you are going to pass along gss-acceptor-realm-name, you need to verify it's one of your realms.
You might want to consider verifying that the host in question is permitted to offer the service in question.
So, my assumption is that permitting the attribute without running those checks is not great.
So, I'd support putting together a sample policy to do those checks for FR, and having commented out proposed lines in the attribute filter stuff reminding people to turn on such a sample policy if they are going to enable the attributes.
Thoughts?
--Sam
Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
not-for-profit company which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
|