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 "XML File Context Provider"

Line 6: Line 6:
 
[https://forgesvn1.novell.com/viewsvn/bandit/trunk/IdentityAbstraction/conf/realms.xsd?content-type=text%2Fplain Configuration XML Schema]
 
[https://forgesvn1.novell.com/viewsvn/bandit/trunk/IdentityAbstraction/conf/realms.xsd?content-type=text%2Fplain Configuration XML Schema]
  
One example configuration file ([http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.higgins/plugins/org.eclipse.higgins.idas.cp.jndi.test/context-test.config.xml?root=Technology_Project&view=markup context-test.config.xml]) and one generated configuration file (testRealm.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_CVS | JNDI CP Projects]].
+
One example configuration file ([http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.higgins/plugins/org.eclipse.higgins.idas.cp.jndi.test/context-test.config.xml?root=Technology_Project&view=markup context-test.config.xml]) and one generated configuration file (testRealm.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_CVS | 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.
 
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.

Revision as of 12:53, 19 March 2007

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

One example configuration file (context-test.config.xml) and one generated configuration file (testRealm.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>

env

The JNDI CP will attempt to support all java.naming.* environment properties as far as they make sense to support for each JNDI provider supported. Any given environment property may be honored by any number of Context Providers which use this configuration format. Consult the Context Provider specific env element documentation for which env elements are supported. The env elements can be specified at both a global and realm (Context) specific level.

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