„Attribute Conversion for eduGAIN” változatai közötti eltérés

Innen: KIFÜ Wiki
(Új oldal, tartalma: „JRA5 Attribute Conversion allows a Bridging Element administrator to define rules to transform attributes being released or received. The same logic can work in both Home ...”)
 
(Writing rules)
6. sor: 6. sor:
  
 
Attribute Conversion only adds attributes (or values) to the attribute set; use [[JRA5AttributeFiltering | Attribute Filtering]] for filtering out unnecessary attributes. It also means that if no rules match an attribute, then it will go to the filter unmodified - so conversion works with a '''default by-pass policy'''.
 
Attribute Conversion only adds attributes (or values) to the attribute set; use [[JRA5AttributeFiltering | Attribute Filtering]] for filtering out unnecessary attributes. It also means that if no rules match an attribute, then it will go to the filter unmodified - so conversion works with a '''default by-pass policy'''.
== Writing rules ==
+
== Attribute conversion rule concepts==
 
Most of the rules are based on standard [http://en.wikipedia.org/wiki/Regular_expression regular expressions] and [http://en.wikipedia.org/wiki/Unified_Expression_Language Unified Expression Language].  
 
Most of the rules are based on standard [http://en.wikipedia.org/wiki/Regular_expression regular expressions] and [http://en.wikipedia.org/wiki/Unified_Expression_Language Unified Expression Language].  
  
 
Each rule works on the actual attribute set which is not necessarily the initial set, as each rule can alter the set (ie. by changing values or names, adding new attributes to the set). This means that the '''order of the rules is important'''.
 
Each rule works on the actual attribute set which is not necessarily the initial set, as each rule can alter the set (ie. by changing values or names, adding new attributes to the set). This means that the '''order of the rules is important'''.
  
Rules can contain a Condition element to declare the conditions when the rule matches. Matches can be defined for
+
Every rule consists of two parts: condition and action. The condition element is used to determine whether this particular rule is to be processed or not. Thus, the rule action is only processed when all the conditions are met (a rule without any conditions is processed by default).
 +
 
 +
The condition engine now only supports regular expression -based matching rules. There is two type of matching rules
 
* remote peer's name (RemoteProviderMatch)
 
* remote peer's name (RemoteProviderMatch)
* attribute name
+
* attribute values (AttributeMatch)
* attribute value
+
 
 +
The rule's action is to create new attributes (or to modify existing ones). Please refer to the detailed BasicRule, MergeRule, SplitRule documentation below.
 +
 
 +
 
 +
=== Rule context ===
 +
When the conversion rules are processed one after another, each rule has its own rule context bound to it. This context holds references to all the matched attributes too. The rule context is also responsible for supporting the rule's action.
  
A rule without a condition is evaluated as <code>.*</code>: it matches by default. A rule is only processed for the first matching attribute. Because the order of the attributes is undetermined, you should avoid using too general conditions.
+
 
 +
== Attribute conversion rule types ==
 
=== BasicRule ===
 
=== BasicRule ===
 
=== MergeRule ===
 
=== MergeRule ===
22. sor: 30. sor:
 
=== CustomRule ===
 
=== CustomRule ===
 
=== Quick guide for using unified EL with rules ===
 
=== Quick guide for using unified EL with rules ===
 +
 
== Using name mapper ==
 
== Using name mapper ==
 
== Testing ==
 
== Testing ==
 
=== XMLTest.sh ===
 
=== XMLTest.sh ===
 
=== Real-life examples ===
 
=== Real-life examples ===

A lap 2008. szeptember 3., 12:46-kori változata

JRA5 Attribute Conversion allows a Bridging Element administrator to define rules to transform attributes being released or received. The same logic can work in both Home and Remote Bridging Elements.

Introduction

Attributes:The Big Attribute Picture

Attributes are travelling on the wire in eduGAIN-defined format, ie. SAML. Naming attributes and defining their contents might be a standardization task of eduGAIN operators; however it should be possible for federations to agree on custom set of attributes beyond "eduGAIN commons".

Attribute Conversion only adds attributes (or values) to the attribute set; use Attribute Filtering for filtering out unnecessary attributes. It also means that if no rules match an attribute, then it will go to the filter unmodified - so conversion works with a default by-pass policy.

Attribute conversion rule concepts

Most of the rules are based on standard regular expressions and Unified Expression Language.

Each rule works on the actual attribute set which is not necessarily the initial set, as each rule can alter the set (ie. by changing values or names, adding new attributes to the set). This means that the order of the rules is important.

Every rule consists of two parts: condition and action. The condition element is used to determine whether this particular rule is to be processed or not. Thus, the rule action is only processed when all the conditions are met (a rule without any conditions is processed by default).

The condition engine now only supports regular expression -based matching rules. There is two type of matching rules

  • remote peer's name (RemoteProviderMatch)
  • attribute values (AttributeMatch)

The rule's action is to create new attributes (or to modify existing ones). Please refer to the detailed BasicRule, MergeRule, SplitRule documentation below.


Rule context

When the conversion rules are processed one after another, each rule has its own rule context bound to it. This context holds references to all the matched attributes too. The rule context is also responsible for supporting the rule's action.


Attribute conversion rule types

BasicRule

MergeRule

SplitRule

CustomRule

Quick guide for using unified EL with rules

Using name mapper

Testing

XMLTest.sh

Real-life examples