 |
 |
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