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

XML File Context Provider

Configuration

NOTE: The XML File Context Provider configuration XML file format was designed to be used to configure any number and type of Context Provider. Other Higgins Context Providers contributed by Novell currently use this same format. Work is currently underway which may change or eliminate this method of CP configuration.

The XML File Context Provider is configured through an XML file whose format is specified by the following XML schema:

Configuration XML Schema

Two example configuration files (testRealm.xml) and (testRealm2.xml) are available in the org.eclipse.higgins.idas.cp.xmlfile.test project. Instructions on how to access this project is available here: XML File CP Projects.

Each Context configuration section is described by a "Realm" definition within the XML file. For purposes of this documentation, the terms "Realm" and "Context" are synonymous.

Realm Configuration Elements

realms

This element should encapsulate all realm definitions and other global configuration. This element should also define the namespaces to be used globally throughout the configuration document.

<bci:realms
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:bci="http://www.bandit-project.org/commonidentity"
   xmlns:xacml="urn:oasis:names:tc:xacml:2.0:policy:schema:os"
   xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:policy:schema:os:access_control-xacml-2.0-policy-schema-os.xsd">
   ...
</bci:realms>

XML File CP TODO

  1. The getSchema() needs to be updated to follow the latest ontology.
  2. The format of the identity data should more closely follow the Higgins data model and, since we control it, we can structure the XML however we want. Besides, I don't like the file format as it stands anyway. In addition, if we structure it right, we won't have to do any mapping of types from the XML to Higgins, it can just BE what we expect in Higgins or even the consuming application (ie. CardSpace claims). At any rate, currently, that's not the case.
  3. Respond to registry and configuration model changes when they are completed. #2 should be done in conjunction w/ this.
  4. Allow updates through IdAS APIs.

See Also

Back to the top