JRA5Attributes - Laptörténet

Sitya(AT)niif.hu, 2011. április 5., 12:18-n

2011-04-05T12:18:20Z

Bajnokk(AT)niif.hu: obsolete

2008-09-01T14:18:47Z

obsolete

Bajnokk(AT)niif.hu: /* Filtering */

2007-11-26T10:52:31Z

‎Filtering

Bajnokk(AT)niif.hu: Filtering stub

2007-11-26T10:43:31Z

Filtering stub

Bajnokk(AT)niif.hu: /* The Shibboleth Way */

2007-11-26T10:42:33Z

‎The Shibboleth Way

Bajnokk(AT)niif.hu: /* The Shibboleth Way */

2007-11-26T10:41:24Z

‎The Shibboleth Way

Bajnokk(AT)niif.hu: /* Pluggable Conversion Engines */

2007-11-26T10:26:09Z

‎Pluggable Conversion Engines

Bajnokk(AT)niif.hu: /* eduGAIN Credential Conversion Service (''eCCS'') */

2007-11-26T09:27:53Z

‎eduGAIN Credential Conversion Service (''eCCS'')

Bajnokk(AT)niif.hu: not yet ready

2007-11-26T07:34:23Z

not yet ready

Bajnokk(AT)niif.hu: not yet ready

2007-11-26T07:33:09Z

not yet ready

@@ 40. sor: / 40. sor: @@
 Shibboleth2 has a number of built-in <code>AttributeDefinition</code>s:
-* [https://spaces.internet2.edu/display/SHIB2/ResolverSimpleAttributeDefinition SimpleAttributeDefinition]: pass through the retrieved value of the attribute
+* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverSimpleAttributeDefinition SimpleAttributeDefinition]: pass through the retrieved value of the attribute
-* [https://spaces.internet2.edu/display/SHIB2/ResolverScopedAttributeDefinition ScopedAttributeDefinition]: append a scope to the attribute value
+* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScopedAttributeDefinition ScopedAttributeDefinition]: append a scope to the attribute value
-* [https://spaces.internet2.edu/display/SHIB2/ResolverTemplateAttributeDefinition TemplateAttributeDefinition]: sets value based on an arbitrary template of constant string and other attributes
+* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverTemplateAttributeDefinition TemplateAttributeDefinition]: sets value based on an arbitrary template of constant string and other attributes
-* [https://spaces.internet2.edu/display/SHIB2/ResolverMappedAttributeDefinition MappedAttributeDefinition]: sets value according to conditions on (possibly other) attribute values
+* [https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverMappedAttributeDefinition MappedAttributeDefinition]: sets value according to conditions on (possibly other) attribute values
-* [https://spaces.internet2.edu/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.
+* [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 ====

← Régebbi változat		A lap 2008. szeptember 1., 14:18-kori változata
1. sor:		1. sor:
		+	{{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.		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.

← Régebbi változat		A lap 2007. november 26., 10:52-kori változata
52. sor:		52. sor:
	* Amount of code needs to be included into eduGainBase is unknown. Worst case: whole Java Shibboleth library (<code>edu.internet2.middleware.shibboleth.common.*</code>)		* 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 ==		== 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

← Régebbi változat		A lap 2007. november 26., 10:43-kori változata
51. sor:		51. sor:
	* Licencing issue (Shibboleth has Apache2 style licence)		* 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>)		* 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 ==

@@ 33. sor: / 33. sor: @@
 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).
+It can be used for attribute conversion in eduGAIN as well if we can define a <code>DataConnector</code> that can use attributes retrieved
 Shibboleth2 has a number of built-in <code>AttributeDefinition</code>s:

← Régebbi változat		A lap 2007. november 26., 10:26-kori változata
30. sor:		30. sor:
	* 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.		* 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://spaces.internet2.edu/display/SHIB2/ResolverSimpleAttributeDefinition SimpleAttributeDefinition]: pass through the retrieved value of the attribute
		+	* [https://spaces.internet2.edu/display/SHIB2/ResolverScopedAttributeDefinition ScopedAttributeDefinition]: append a scope to the attribute value
		+	* [https://spaces.internet2.edu/display/SHIB2/ResolverTemplateAttributeDefinition TemplateAttributeDefinition]: sets value based on an arbitrary template of constant string and other attributes
		+	* [https://spaces.internet2.edu/display/SHIB2/ResolverMappedAttributeDefinition MappedAttributeDefinition]: sets value according to conditions on (possibly other) attribute values
		+	* [https://spaces.internet2.edu/display/SHIB2/ResolverScriptAttributeDefinition ScriptAttributeDefinition]: 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 ...

@@ 18. sor: / 18. sor: @@
 === eduGAIN Credential Conversion Service (''eCCS'') ===
-Defining rules for attribute transformation has come up in different areas. Shibboleth uses <code>*AttributeDefinition</code> elements to define conversion rules from data source (e.g LDAP) attributes to released attributes.
+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.

@@ 2. sor: / 2. sor: @@
 == Conversion ==
 Regardless of attribute representation of each federation (eg. Attribute Certificates or simple string values), users want to transport the ''information'' included in attribute values. The aim of attribute conversion is to let BE administrators be able to define rules for including and extracting information into/from attributes that can be handled by both federations.
 It is worth noting that inside the two federations they can embed
 * the same information into different attribute-value pairs, eg. <code>fooFedHospitalWard: urn:foo:surgery</code> and <code>barFedAbteilung: urn:bar:Chirurgie</code> could carry the same information ("a medical institution has surgical ward"), while
-* the same attribute-value pairs can carry different information, eg. <code>eduPersonAffiliation: student</code>
+* the same attribute-value pairs can carry different information, eg. <code>eduPersonAffiliation: student</code> could be used for higher educational students only in one federation but in the other this could mean everybody studying in education (from primary schools to PhD).

@@ 1. sor: / 1. sor: @@
-According to the bridged model of EduGAIN, SPs treat Remote Bridging Elements as ordinary IdPs of the federation they belong and the same applies to the relation between RBE <-> HBE and HBE <-> IdP.
+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.
-When a Home Bridging Element releases local attributes to a remote federation, some attribute transformation and attribute filtering must take place. Similarly, Remote BE has to filter out unnecessary/unwanted attributes and transform the remaining according to its federation's rules.
+It is worth noting that inside the two federations they can embed
+* the same information into different attribute-value pairs, eg. <code>fooFedHospitalWard: urn:foo:surgery</code> and <code>barFedAbteilung: urn:bar:Chirurgie</code> could carry the same information ("a medical institution has surgical ward"), while
+* the same attribute-value pairs can carry different information, eg. <code>eduPersonAffiliation: student</code>