Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Context Provider"

(Overview)
(Responsibilities of an IContext implementation)
Line 33: Line 33:
 
Optional IContext implementation responsibilities
 
Optional IContext implementation responsibilities
 
# Authentication to add a new [[I-Node]] to the context
 
# Authentication to add a new [[I-Node]] to the context
# Authorization of access to [[Digital Subject]] profile data using role-based access control lists
+
# Authorization of access to [[I-Node]] [[Attribute]]s using role-based access control lists
 
# Support for finding [[I-Node]]s by query
 
# Support for finding [[I-Node]]s by query
 
# Ability to associate [[I-Node]]s to other [[I-Node]]s within the same context
 
# Ability to associate [[I-Node]]s to other [[I-Node]]s within the same context

Revision as of 14:33, 3 February 2008

Overview

A Context Provider adds support for one or more kinds of Contexts to the Identity Attribute Service framework. These Contexts contain I-Nodes that hold Attributes. A context provider is responsible for its internal data management, security, encryption, persistence, etc. The provider provides the uni- or bi-directional transformation of data from its internal structures to the normalized IdAS data model. In many cases these Context Providers act as adapters or "wrappers" of existing services such as communications systems, collaboration systems, social networks, identity providers, games, enterprise apps, and so on. In addition to web services, Context Providers can also adapt client-side applications such as email clients, IM and other messaging and collaboration apps.

Here is a list of existing Higgins Context Providers.

Relationship between Context Providers, Context Factories, and Contexts

  • Multiple Context Factories may be registered with a single IdAS
  • A Context Provider is a packaging/deployment wrapper around one or more Context Factories, which in turn produce Context instances and the data they hold
  • A Context Factory may provide access to multiple Contexts
  • Multiple Context Providers (using their associated Context Factories) may provide access to the same Context.
    • An example of this might be using different LDAP engines to access the same underlying data store

Responsibilities of a ContextFactory

  1. createContext(URI) - create a Context object for a given reference
  2. getContexts(String filter) - return the set of Context References (URIs) that are currently open and are managed by this provider [this method is under review]
  3. getPolicy() - returns the policy in effect for this Context Provider. This policy must include a list of the required and optional Claims required to open any (is the word "any" correct here?) context managed by this provider


Responsibilities of an IContext implementation

  1. Maintain the set of I-Nodes that exist in this context and conform to its schema.
    • The underlying bits that represent the I-Nodes might be in an LDAP directory, a text file, or an IM chat client The Context Provider's IContext implementation is responsible for translation and mapping from the underlying representation to the Higgins Data Model.
    • The Context Provider certainly needs to know what the storage technology is and how to use it. It could also source data from many different formats, presenting the results as a unified Context with a specific schema.
    • But the Context Provider also represents a specific vendor's (or author's) code to implement that transformation. So it's possible to have a Novell-LDAP provider and an IBM-LDAP provider.
  2. Support addition, deletion, and navigation of contained I-Nodes as allowed by the context's policy
  3. Support update and deletion of attributes of contained I-Nodes as allowed by the context's policy
  4. Provide the ability to export and import the contents of a context to an RDF data stream
  5. Act as a container of references to sub-Contexts
  6. Maintain (and return on request) the policies related to various kinds of access to I-Nodes
  7. Provide access to the schema which governs the form of I-Nodes in this context.
  8. Open the context for a particular Digital Identity as allowed by the context's policy.
  9. Close context, preventing further access via this object.

Optional IContext implementation responsibilities

  1. Authentication to add a new I-Node to the context
  2. Authorization of access to I-Node Attributes using role-based access control lists
  3. Support for finding I-Nodes by query
  4. Ability to associate I-Nodes to other I-Nodes within the same context
  5. Support for adding tag properties to [[I-Node]]s and on the associations between [[I-Node]]s
  6. Replication/distribution/synchronization of context data with external systems (and directly or indirectly, other Higgins frameworks)
  7. Persistence and encryption of context data
  8. Reputation computation

Current Java Impl

In the Java reference implementation a Context Provider implements the IContextFactory and IContext interfaces. Implementations of this interface and the associated IContextProvider interface are usually packaged as an Eclipse plug-in (or more properly an OSGI bundle). See also: IdAS Context Provider Registry

See Also

Links

Back to the top