Preparing for Moonshot Meeting
We are in the final stages of preparation for our meeting September 21. Participants should take a look at the reading list for the technical discussions at the meeting.
The moonshot-community list has been very active over the past two weeks. This discussion has set the stage for several of the topics at the meeting. Most of the messages were in a 43-message thread exploring how the Shibboleth Service Provider and GSS-API mechanism interact with RADIUS and SAML. As we discussed in our briefing paper, Moonshot will allow applications to use AAA/RADIUS and SAML to provide information about the subject user to a federated service provider. Several important points were made during this discussion.
There are two approaches applications can use in Moonshot for getting at information. The GSS-API Naming Extension API provides a C-based interface for basic operations. Shibboleth provides a C++ API that is more extensive than the naming extensions API.
The raw sources of information such as SAML or RADIUS attributes are not what applications typically want to deal with. Information can be stored in a number of locations depending on the IDP’s profile. Local policy needs to be applied to filter attributes. Some of the issues are discussed here and others were discussed in the moonshot-community discussion. For this reason, Shibboleth filters and maps input attributes such as SAML attributes into local Shibboleth attributes.
The GSS-API is also converging on a similar model. There was discussion of these issues at the kitten meeting of the most recent IETF. There people discussed permitting local attributes to be used.
Shibboleth definitely provides a lot of value for Moonshot. However we may want to have some more limited functionality available if the GSS mechanism is not built against Shibboleth.
Side discussions also focused on how RADIUS attributes will be represented. Natively, RADIUS attributes can be described by a set of integers. This is not convenient for application authors. Standardized attributes may have consistent names. RADIUS implementations typically provide mappings from all attributes they understand, including vendor attributes, to names. However the names are not standardized. Clearly application authors and system administrators will need convenient names to use. However, the question about where this mapping should take place is open.
[...] the end of September, things were quite exciting as we had our first project meeting. At that meeting those in the room saw a demonstration of the Moonshot GSS EAP mechanism and we [...]