547
szerkesztés
Módosítások
nincs szerkesztési összefoglaló
When a Home Bridging Element releases local attributes to a Remote Bridging Element, some attribute transformation and attribute filtering should take place. Similarly, Remote BE has to filter out unnecessary/unwanted attributes and transform the remaining according to its federation's rules.
In the former case, conversion is independent of the relying party, all what BEs need to do is to convert to and from the ''common format''. However, maintaining a central vocabulary is not always easy and is quite hard to make it flexible enough. It should be possible to allow federations to define custom interfaces for talking to specific peers.
=== eduGAIN Credential Conversion Service (''eCCS'') ===
Gabriel López et al. describe a common [[Media: eccs.pdf | 'eduGAIN Credential Conversions Service']].
==== Summary ====
They propose a central (although technically distributable) service for carrying out attribute conversion to and from a common representation (eduGain Common Credentials, ''eCC''). Conversion polices for converting local attributes to ''eCC'' and vice versa are included in the metadata. Attributes can be transferred between BEs in ''eCC'' representation and in 'source format' (in unconverted form). In both cases an RBE needs to invoke ''eCCS'', which sends back attributes in the required format of the remote federation.
eCCS operates by utilizing custom SAML extensions called ''ConversionQuery'' and ''WrappedStatement'' as well as conversion policy sets (XACML) published in metadata. Probably the most important thing in eCCS is to '''eliminate the NxN matrix problem''' (where N is the number of BEs), because of conversion policies published in MDS.== Conversion ==Comments ====* eCCS '''MUST''' be distributed and very close to the BE because of maintaining '''privacy'''. No central elements (outside the scope of the 2 federations) shall ever receive users' attributes.* Representing every possible conversion scenarios in conversion policy might be quite difficult* It would be quite hard if even possible to define custom 'common formats' between subsets of federations using the 'big' eduGAIN MDS. It would be necessary if some federations have different levels of cooperations requiring different attributes. === Approaches The Shibboleth Way ===Ways of solving Shibboleth uses <code>*AttributeDefinition</code> elements to define conversion rules from data source (i.e. LDAP) attributes to "resolved" attributes. <code>AttributeDefinition</code>s can depend on <code>DataConnector</code>s or other <code>AttributeDefinition</code>s. It can be used for attribute conversion problem in eduGAIN as well if we can define a <code>DataConnector</code> that can use attributes retrieved * from the IdP (at the HBE), or * from simple the HBE (at RBE). Shibboleth2 has a number of built-in <code>AttributeDefinition</code>s:* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverSimpleAttributeDefinition SimpleAttributeDefinition]: pass through the retrieved value of the attribute* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScopedAttributeDefinition ScopedAttributeDefinition]: append a scope to advancedthe attribute value* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverTemplateAttributeDefinition TemplateAttributeDefinition]: sets value based on an arbitrary template of constant string and other attributes* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverMappedAttributeDefinition MappedAttributeDefinition]: sets value according to conditions on (possibly other) attribute values* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinition ScriptedAttributeDefinition]: execute a [https://scripting.dev.java.net/ JSR-223] (Java) script to determine the attribute value. This script gets the context information in <code>requestContext</code> variable.* ... and some others ...====Hooking into EduGAIN = Limited set of common attributes ===It is still necessary to define an attribute vocabulary within a confederation, however it is technically easier to exchange additional attributes between relying parties. If 'EduGAIN' as a confederation can be one of the relying parties (and why not?), then the NxN matrix problem can be avoided, because only 'special' relying parties (peers) require additional configuration. :: TODO: does EduGAIN have the notion "relying party"?====Open issues = Customized attribute conversion done BE's ===* Licencing issue (Shibboleth has Apache2 style licence)* Amount of code needs to be included into eduGainBase is unknown. Worst case: whole Java Shibboleth library (<code>edu.internet2.middleware.shibboleth.common.*</code>)==Filtering = Metadata-=Both HBE and RBE need to filter the set of attributes released and accepted. Shibboleth2 comes with a filtering code that is the same both for the attribute publisher and the consumer. Filtering rules may be based on (among others):* requester/issuer* attribute conversion service ===values* authentication context