„JRA5Attributes” változatai közötti eltérés

Innen: KIFÜ Wiki
(not yet ready)
(not yet ready)
2. sor: 2. sor:
  
 
== Conversion ==
 
== 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.  
+
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
 
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 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).
 +
 
 +
It is possible that in some cases the information that needs to be transferred is hold by a tuple of attributes. Sometimes the number of attributes representing the same information can differ in each federation. In these cases simple translation of attribute names and values is not enough.
 +
 
 +
=== Information needed for conversion ===
 +
Naturally, federations need to agree on the vocabulary when exchanging these kinds of information. It can be achieved in the following ways:
 +
* the confederation maintains a common vocabulary of allowed attribute values
 +
* peers agree on attribute value interfaces (what Home sends and Remote accepts), independently of the confederation
 +
 
 +
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'') ===
 +
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.
 +
 
 +
However the most closely related work is a paper from Gabriel López et al. called [[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.
 +
==== 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.
 +
 
 +
=== Pluggable Conversion Engines ===

A lap 2007. november 26., 08:34-kori változata

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.

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. fooFedHospitalWard: urn:foo:surgery and barFedAbteilung: urn:bar:Chirurgie could carry the same information ("a medical institution has surgical ward"), while
  • the same attribute-value pairs can carry different information, eg. eduPersonAffiliation: student 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).

It is possible that in some cases the information that needs to be transferred is hold by a tuple of attributes. Sometimes the number of attributes representing the same information can differ in each federation. In these cases simple translation of attribute names and values is not enough.

Information needed for conversion

Naturally, federations need to agree on the vocabulary when exchanging these kinds of information. It can be achieved in the following ways:

  • the confederation maintains a common vocabulary of allowed attribute values
  • peers agree on attribute value interfaces (what Home sends and Remote accepts), independently of the confederation

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)

Defining rules for attribute transformation has come up in different areas. Shibboleth uses *AttributeDefinition elements to define conversion rules from data source (e.g LDAP) attributes to released attributes.

However the most closely related work is a paper from Gabriel López et al. called '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.

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.

Pluggable Conversion Engines