547
szerkesztés
Módosítások
nincs szerkesztési összefoglaló
{{TRASH}}
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.
=== eduGAIN Credential Conversion Service (''eCCS'') ===
==== 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.
* 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.
=== Pluggable Conversion Engines The Shibboleth Way ===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 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 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 the 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 ====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 ====* 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 ==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 values* authentication context
