Hi,

> I was thinking more of an identifier so I don't have to send a SAML assertion to every local RADIUS request (I'm narrowing down when I send the SAML assertion). 

moonshot queries will have some extra attibutes present

> Unless of course it's this attribute that I have noticed (which remains the same for every request): X-Ascend-FR-DCE-N393, which appears to be an 'illegal' attribute from Ascend (it's in the .illegal dictionary). I searched for that attribute online and it appears there's a clash between the old Ascend and the new GSS-Acceptor attributes in dictionary.ukerna? 

thats a dictionary clash - you shouldnt be using the illegal dictionaries unless you REALLY REALLY
need to - eg you actually have Ascend kit and still use those attributes

> When I search around for these attributes, I find a JISCMail post from Sam mentioning a FR dictionary patch (once a casing issue is resolved). Is that patch mentioned here https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=MOONSHOT-COMMUNITY;4a29ccef.1209 for dictionary.ukerna?

there is now an official IANA ID for the moonshot stuff:


ATTRIBUTE	GSS-Acceptor-Service-Name	164	string
ATTRIBUTE	 GSS-Acceptor-Host-Name	165	string
ATTRIBUTE	GSS-Acceptor-Service-Specifics	166	string
ATTRIBUTE	GSS-Acceptor-Realm-Name	167	string

(as that posting noted) - I'll need to dig out the proper IANA doc 

> If that is the case, does SAML-AAA-Assertion keep the attribute number it currently has?

I'll double check (and MS-Windows-Auth-Data) 

alan