> 2) Require that the GSS-EAP implementation understand the type and > multi-value semantics of anything it exposes. That's kind of undesirable > because we want the GSS-EAP implementation to eventually be a component > of the operating system and we expect deployments to extend the set of > attributes thought the use of vendor-specific attributes. We expect > facilities like Shibboleth to be able to map AAA attributes into local > attributes under the control of a configuration file.
I specifically have to know what formats, if any, I would need to implement support within Shibboleth (or more accurately in an extension of it) for using as input. I have been expecting to build something that operates on the GSS context via the naming extensions to pull out non-SAML information and be able to process it, but that obviously requires additional configuration of some sort. It seems like a bad thing to require that sort of configuration in both places, though. I was expecting that if Shibboleth was going to be chewing on RADIUS attributes that there wouldn't need to be anything in the way of extra configuration in the GSS layer to make them available. -- Scott _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
