From 906eb4666987171915a8cec7e024523a1917ac99 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/9s1IqWsahpHPqgBknM7zgI4SqW.p#29ad7" Date: Sat, 11 Jun 2011 15:46:03 -0400 Subject: [PATCH] Added Shibboleth usage information --- prepare.mdwn | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/prepare.mdwn b/prepare.mdwn index da84a2e..46ee96f 100644 --- a/prepare.mdwn +++ b/prepare.mdwn @@ -54,3 +54,53 @@ $secret is the secret you share with the radius server, i.e. the "secret" entry Todo: * Set up RADIUS +# Using the Shibboleth SP + +You can use the Shibboleth SP implementation as a value-added processing layer for RADIUS AVPs or SAML information obtained from the authenticating RADIUS service. The features of the SP are currently leveraged through the mech_eap GSS mechanism implementation. The information obtained from the RADIUS server is attached to the GSS security context as GSS naming extension attributes. The attributes may be simple string name/value pairs, SAML assertions, or even binary objects. The SP's attribute manipulation layers can be configured to map these GSS attributes into locally-defined alias, filter them according to policies, or use them to obtain additional information using, for example, SAML queries. + +## Technical Setup + +Currently there is no build option for mech_eap that doesn't include the SP; this is likely to change in the future, but at the moment, the SP's libraries are always used in the build. The version used by the mechanism is unreleased code that will be part of the 2.5 SP release, and requires the latest development branches of the Shibboleth and OpenSAML libraries. + +Out of the box, the SP "initializes" successfully but doesn't do anything particularly useful in most cases. Configuration of the SP is essentially the same as in the more usual Web SSO case, except that not all of the usual parts are relevant. + +The current mech_eap instantiates the SP "in-process". This entails a certain degree of overhead and behavior from the SP that may be undesirable. As an example, access to local and remote configuration files involves the use of background threads to maintain currency; this reload capability could be disabled to improve startup time and limit resource usage. + +A more practical direction will be to make use of the SP's support for offloading processing to the shibd daemon that is used in the typical web deployment. This is discussed below. + +### Metadata + +Ordinarily metadata is a hard requirement for the SP to function, but this is less true with Moonshot. The main need for metadata will be if you wish to rely on attribute filtering policies that rely on it, chiefly the "scope" extension that allows the SP to filter out scoped attributes like eduPersonPrincipalName based on the source of the attribute. This is generally applicable only to SAML-sourced attributes, and in such cases the issuer of the assertion is the entity for which metadata is needed. + +For the time being, the "normal" metadata used for SAML 2.0 IdPs is sufficient to drive the filtering engine. Moonshot-specific metadata may be defined in the future. + +### Attribute Configuration + +The SP's three attribute subsystems are all usable with Moonshot. + +[[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeExtractor]] + +[[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeFilter]] + +[[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeResolver]] + +SAML assertions are automatically identified by mech_eap and passed in for processing, using the same XML-based extractor plugin that is familiar to Shibboleth deployers, configured via the "attribute-map.xml" file. + +This same file format has been extended to support direct extraction of GSS naming extension attributes via a new "GSS" extractor plugin. To make this plugin available, it must be loaded: + + + + + + + +Within the "attribute-map.xml" file, you can create mappings for GSS extensions as follows: + + + +The "name" matches the naming extensions's identifier and the "id", as usual, is a local name for the attribute that may be more convenient for application use. You can also map multiple SAML or GSS attributes to the same local "id" to collapse multiple attribute types into one canonical form. + +Other XML attributes defined for the element: + +*authenticated="true|false" - allows processing to proceed only if the GSS attribute is authenticated +*binary="true|false" - treats the GSS attribute as binary-valued -- 2.1.4