Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Org.eclipse.higgins.iss"
(→Overview) |
(→Details) |
||
| (19 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} | |
| − | + | The [[org.eclipse.higgins.iss]] uses a policy engine to attempt to determine a matching between the Relying Party's Security Policy and one or more I-Cards that can satisfy that policy. | |
| − | |||
| − | |||
| − | + | ==Service== | |
| + | I-Card Selector Service is an extension of [[Registry]] which manages loading and configuration of plugins that implements IICardSelector interface. | ||
| − | + | ===Responsibilities=== | |
| + | * Determine a matching between the Relying Party's Security Policy and one of IICardSelectors that in turn determine matching I-Cards that can satisfy that policy. | ||
| + | * Provide convinient way to call getIdentityToken method of apropriate IICardSelector. | ||
| − | + | ===Dependencies=== | |
| + | * [[I-Card Registry]] | ||
| + | * [[Token Service]]??? | ||
| − | + | ===API=== | |
| + | // Iterate through cards in the [[I-Card Registry]], use Policy engine | ||
| + | // to examine the supported claim of each to find one or more cards that | ||
| + | // singly or together satisfy the policy. Invoke the [[ISS Web UI]] | ||
| + | // if 'hbx' is true, else invoke the [[ISS Client UI]] to display all cards | ||
| + | // highlighting matching card(s). After user selects card(s), | ||
| + | // getDigitalIdentity from the card(s) (combining DIs if needed?) | ||
| + | IDigitalIdentity getDigitalIdentity(RPSPolicy policy, boolean hbx) | ||
| + | |||
| + | // (Presuming that only one card matched, and of course that the | ||
| + | // card was a URICard for which IdAS can connect and open a Context) | ||
| + | // Return the Context of the selected card. | ||
| + | IContext getContext(RPSPolicy policy) | ||
| + | |||
| + | // Return a URI to a network endpoint (e.g. an OpenID IdP) that the | ||
| + | // RP will interact with directly --Higgins steps out of the flow | ||
| + | URI getURI(RPSPolicy policy) | ||
| + | |||
| + | // Matching functionality is now exposed by the ISS | ||
| + | Choices match(RPSPolicy policy) throws UnsatisfiablePolicyException | ||
| − | + | ===PolicyFactory Interface=== | |
| − | + | PolicyFactory: This class has one method which instantiates a class that | |
| + | exposes the Policy interface below for the given policy type. | ||
| − | + | Policy ParsePolicy(String policy, String type) throws PolicyParseException, UnsupportedPolicyTypeException | |
| − | + | The factory implementation is quite simple, but it allows for | |
| − | + | extensibility---various different policies can be registered and | |
| − | + | instantiated dynamically, etc. | |
| − | == | + | ===Policy Interface=== |
| − | + | ||
| − | + | // contains the parser for the policy string | |
| − | + | new(String policy) throws PolicyParseException | |
| − | * [[ | + | |
| + | // matches the policy and returns a list of lists indicating the user choices | ||
| + | // can return an empty Choices structure if no choices are needed | ||
| + | Choices match(Icard Registry) throws UnsatisfiablePolicyException | ||
| + | |||
| + | // makes a token which satisfies this policy using the Selection of credentials | ||
| + | DigitalIdentity getDigitalIdentity(Selection) throws InvalidSelectionException | ||
| + | |||
| + | |||
| + | |||
| + | ===The Cardspace Policy Class=== | ||
| + | The cardspace policy class implementation of _new_ would parse the policy. | ||
| + | The _match_ method would subsume the role of the ISS as it is currently described. In particular, it would | ||
| + | iterate through the list of cards retrieved from the registry, call | ||
| + | isMatch on each one, and return a list of those which matched. | ||
| + | |||
| + | The getDigitalIdentity would simply call the similar function of the underlying I-card. | ||
| + | |||
| + | ===Idemix Policy Class=== | ||
| + | An Idemix policy class implementation would have the flexibility to do | ||
| + | more complicated matching, and more complicated processing to get the | ||
| + | token. | ||
| + | |||
| + | Given these two classes, the RP protocol support class would then handle | ||
| + | the details of marshalling/unmarshalling, formatting parameters and | ||
| + | inputs, and making the right calls to the PolicyFactory and resulting | ||
| + | Policy class. | ||
| + | |||
| + | This architecture allows for many more interop possibilities. Anyone | ||
| + | who can implement a policy language for _requesting_ such credentials | ||
| + | can plug into this. | ||
| + | |||
| + | ==Links== | ||
| + | * [http://www.eclipse.org/higgins Higgins Home] | ||
| + | [[Category:Higgins Components]] | ||
Latest revision as of 23:40, 10 July 2009
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} The org.eclipse.higgins.iss uses a policy engine to attempt to determine a matching between the Relying Party's Security Policy and one or more I-Cards that can satisfy that policy.
Contents
Service
I-Card Selector Service is an extension of Registry which manages loading and configuration of plugins that implements IICardSelector interface.
Responsibilities
- Determine a matching between the Relying Party's Security Policy and one of IICardSelectors that in turn determine matching I-Cards that can satisfy that policy.
- Provide convinient way to call getIdentityToken method of apropriate IICardSelector.
Dependencies
API
// Iterate through cards in the I-Card Registry, use Policy engine // to examine the supported claim of each to find one or more cards that // singly or together satisfy the policy. Invoke the ISS Web UI // if 'hbx' is true, else invoke the ISS Client UI to display all cards // highlighting matching card(s). After user selects card(s), // getDigitalIdentity from the card(s) (combining DIs if needed?) IDigitalIdentity getDigitalIdentity(RPSPolicy policy, boolean hbx) // (Presuming that only one card matched, and of course that the // card was a URICard for which IdAS can connect and open a Context) // Return the Context of the selected card. IContext getContext(RPSPolicy policy) // Return a URI to a network endpoint (e.g. an OpenID IdP) that the // RP will interact with directly --Higgins steps out of the flow URI getURI(RPSPolicy policy) // Matching functionality is now exposed by the ISS Choices match(RPSPolicy policy) throws UnsatisfiablePolicyException
PolicyFactory Interface
PolicyFactory: This class has one method which instantiates a class that exposes the Policy interface below for the given policy type.
Policy ParsePolicy(String policy, String type) throws PolicyParseException, UnsupportedPolicyTypeException
The factory implementation is quite simple, but it allows for extensibility---various different policies can be registered and instantiated dynamically, etc.
Policy Interface
// contains the parser for the policy string new(String policy) throws PolicyParseException // matches the policy and returns a list of lists indicating the user choices // can return an empty Choices structure if no choices are needed Choices match(Icard Registry) throws UnsatisfiablePolicyException // makes a token which satisfies this policy using the Selection of credentials DigitalIdentity getDigitalIdentity(Selection) throws InvalidSelectionException
The Cardspace Policy Class
The cardspace policy class implementation of _new_ would parse the policy. The _match_ method would subsume the role of the ISS as it is currently described. In particular, it would iterate through the list of cards retrieved from the registry, call isMatch on each one, and return a list of those which matched.
The getDigitalIdentity would simply call the similar function of the underlying I-card.
Idemix Policy Class
An Idemix policy class implementation would have the flexibility to do more complicated matching, and more complicated processing to get the token.
Given these two classes, the RP protocol support class would then handle the details of marshalling/unmarshalling, formatting parameters and inputs, and making the right calls to the PolicyFactory and resulting Policy class.
This architecture allows for many more interop possibilities. Anyone who can implement a policy language for _requesting_ such credentials can plug into this.