All Element Summary | ||||||||||||
tns:access |
|
|||||||||||
tns:account |
|
|||||||||||
tns:account (type tns:AccountShadowType) | Set of user's accounts.
|
|||||||||||
tns:accountConstruction (type tns:AccountConstructionType) |
|
|||||||||||
tns:accountRef (type tns:ObjectReferenceType) | Set of user's accounts.
|
|||||||||||
tns:accountType (in tns:schemaHandling) | Defiens a type from the resource schema (object
class)
that can be used for creating accounts.
|
|||||||||||
tns:action (in tns:reaction) | Defines an action to take when a situation is
encountered.
|
|||||||||||
tns:activation (type tns:ActivationType) |
|
|||||||||||
tns:additionalNames (type xsd:string) | Middle name, nick name or any other names of a
person.
|
|||||||||||
tns:advanced (in tns:logging) |
|
|||||||||||
tns:allowedIdmGuiAccess (type xsd:boolean) | If true, the user will have access to the IDM
GUI.
|
|||||||||||
tns:and |
|
|||||||||||
tns:append (type xsd:boolean) |
|
|||||||||||
tns:appender (in tns:logging) |
|
|||||||||||
tns:appender (type xsd:string) |
|
|||||||||||
tns:argument (in tns:localizedMessage) |
|
|||||||||||
tns:argument (in tns:script) | Script aguments.
|
|||||||||||
tns:assignment (type tns:AssignmentType) |
|
|||||||||||
tns:assignmentProperty (in tns:entitlementType) | TODO
|
|||||||||||
tns:attribute (in tns:accountConstruction) | Account attribute values implied by
this role.
|
|||||||||||
tns:attribute (in tns:accountType) | Specification of handling of an account
attribute.
|
|||||||||||
tns:attributes (defined in tns:ResourceObjectShadowType complexType) | Attribute values from the resource. | |||||||||||
tns:availableValues (type tns:PropertyAvailableValuesType) |
|
|||||||||||
tns:binding (in tns:task) | TODO loose - tight
If not present the nodes may decide independently.
|
|||||||||||
tns:cachingMetadata |
|
|||||||||||
tns:capabilities (type tns:CapabilitiesType) | The capabilities supported by the resource, including both native capabilities of
the connector and simulated capabilities.
|
|||||||||||
tns:characterClass (type tns:CharacterClassType) |
|
|||||||||||
tns:checkAgainstDictionary (in tns:limitations) |
|
|||||||||||
tns:checkPattern (in tns:limitations) |
|
|||||||||||
tns:claimExpirationTimestamp (in tns:task) | Expiration of the claim.
|
|||||||||||
tns:class (in tns:unknownJavaObject) |
|
|||||||||||
tns:classLogger (in tns:logging) |
|
|||||||||||
tns:clearValue (type xsd:string) |
|
|||||||||||
tns:code (in tns:script) | Script code represented as string.
|
|||||||||||
tns:code (type tns:ExpressionCodeType) | TODO
|
|||||||||||
tns:component (in tns:subSystemLogger) | TODO: components are OR-ed
TODO: string, but
there should be a way how to determine
list of valid
categories.
|
|||||||||||
tns:condition | Boolean condition.
|
|||||||||||
tns:configuration | Resource configuration (hostname, port, ...).
|
|||||||||||
tns:configuration (in tns:connectorFramework) | Global configuration properties of a connector framework. | |||||||||||
tns:confirmation (in tns:synchronization) | Confirmation expression.
|
|||||||||||
tns:connector |
|
|||||||||||
tns:connector (type tns:ConnectorType) | "Composite" version of the ConnectorType
reference.
|
|||||||||||
tns:connectorBundle (type xsd:string) | Name of a package that the connector comes in.
|
|||||||||||
tns:connectorFramework (in tns:systemConfiguration) | Global configuration of connectors and connector frameworks. | |||||||||||
tns:connectorHost |
|
|||||||||||
tns:connectorHost (type tns:ConnectorHostType) | Connector host that hosts this connector.
|
|||||||||||
tns:connectorHostRef (type tns:ObjectReferenceType) | Reference to the connector host that hosts this connector.
|
|||||||||||
tns:connectorPath (in tns:configuration in tns:connectorFramework) | The path to the connector artifacts such as JAR files or directories containing the connector
code.
|
|||||||||||
tns:connectorRef (type tns:ObjectReferenceType) | Reference to the connector that implements
specified resource.
|
|||||||||||
tns:connectorType (type xsd:string) | Type of the connector, as seen by the framework.
|
|||||||||||
tns:connectorVersion (type xsd:string) | Version of the connector.
|
|||||||||||
tns:containedObject (type tns:ObjectType) | Contained object.
|
|||||||||||
tns:containedObjectRef (type tns:ObjectReferenceType) | Reference to the contained object.
|
|||||||||||
tns:correlation (in tns:synchronization) | Correlation expression.
|
|||||||||||
tns:credentials |
|
|||||||||||
tns:credentials (in tns:accountType) | Definition of credentials handling for this account type. | |||||||||||
tns:credentials (type tns:CredentialsType) |
|
|||||||||||
tns:defaultUserTemplate (in tns:systemConfiguration) | User template that will be used "universtally" in all situations regarding user internal consistency.
|
|||||||||||
tns:defaultUserTemplateRef (in tns:systemConfiguration) | Reference to the default user template that will be used "universtally" in all situations regarding
user internal consistency.
|
|||||||||||
tns:dependency (type tns:XPathType) | Defines the XPath of a property on which the
expression
depends.
|
|||||||||||
tns:description | Free-form textual description of the object.
|
|||||||||||
tns:description (type xsd:string) |
|
|||||||||||
tns:details (type xsd:string) |
|
|||||||||||
tns:eMailAddress (type xsd:string) | E-Mail address of the user.
|
|||||||||||
tns:employeeNumber (type xsd:string) | Unique, business-oriented identifier of the
employee.
|
|||||||||||
tns:employeeType (type xsd:string) | Employee type specification such as internal
employee,
external or partner.
|
|||||||||||
tns:enabled (type xsd:boolean) |
|
|||||||||||
tns:encryptProtectedValues (type xsd:boolean) | If set to true the importe errors will be summarized in the result.
|
|||||||||||
tns:entitlement (in tns:accountConstruction) | Assignments implied by this role.
|
|||||||||||
tns:entitlementType (in tns:schemaHandling) | Type of entitlements such as groups, roles
entitlements, organizatrions, etc.
|
|||||||||||
tns:entry (in tns:params) |
|
|||||||||||
tns:equal |
|
|||||||||||
tns:exclusivityStatus (in tns:task) | Exclusivity status tells about task "locking" to a particular node.
|
|||||||||||
tns:executionStatus (in tns:task) | Execution status provides information about the task overall high-level execution state.
|
|||||||||||
tns:expiration (in tns:lifetime) | Number of days before password expires
-1 : means
password doesn't expire
0 : means password is
expired
|
|||||||||||
tns:expression |
|
|||||||||||
tns:extension | Place for non-standard object properties.
|
|||||||||||
tns:failedLogins (in tns:password) | The number of failed logins.
|
|||||||||||
tns:familyName (type xsd:string) | Family name of the user.
|
|||||||||||
tns:fetchResourceSchema (type xsd:boolean) | If set to true the importe errors will be summarized in the result.
|
|||||||||||
tns:fileName (type xsd:string) |
|
|||||||||||
tns:filePattern (type xsd:string) |
|
|||||||||||
tns:filter |
|
|||||||||||
tns:framework (type xsd:anyURI) | Identification of the framework or mechanism
that implements this connector.
|
|||||||||||
tns:fullName (type xsd:string) | Full name of the user with all the
decorations,
middle name initials, honorific title and any
other
structure that is usual in the cultural
environment that the
system operates in.
|
|||||||||||
tns:genericObject |
|
|||||||||||
tns:givenName (type xsd:string) | Given name of the user.
|
|||||||||||
tns:greaterOrEqual |
|
|||||||||||
tns:handlerUri (in tns:task) | Handler URI indirectly specifies which class is responsible to handle the task.
|
|||||||||||
tns:honorificPrefix (type xsd:string) | Honorific titles that go before the name.
|
|||||||||||
tns:honorificSuffix (type xsd:string) | Honorific titles that go after the name.
|
|||||||||||
tns:host (in tns:script) | Defines where the script should be executed
(connector
or resource).
|
|||||||||||
tns:hostname (type xsd:string) | Hostname of a remote host.
|
|||||||||||
tns:ignore | Presence of this element signifies that the strcture that it contains should
be ignored.
|
|||||||||||
tns:inbound (in tns:attribute in tns:accountType) | Defines how the attribute values are used
(assigned) in
case of information flow from resource to
IDM, e.g.
in
case of synchronization, reconciliation or discovery.
|
|||||||||||
tns:interval (in tns:schedule) | Interval in seconds between task invocations.
|
|||||||||||
tns:keepOid (type xsd:boolean) | If set to a true value it will cause that objects that overwritten objects will reuse the same OID
as previous objects.
|
|||||||||||
tns:key (in tns:localizedMessage) |
|
|||||||||||
tns:language (type xsd:anyURI) |
|
|||||||||||
tns:lastFailedLoginTimestamp (in tns:password) | The date and time of last failed login
attempt.
|
|||||||||||
tns:lastRunFinishTimestamp (in tns:task) | TODO
|
|||||||||||
tns:lastRunStartTimestamp (in tns:task) | TODO
|
|||||||||||
tns:lessOrEqual |
|
|||||||||||
tns:level (type tns:LoggingLevelType) |
|
|||||||||||
tns:lifetime (in tns:passwordPolicy) |
|
|||||||||||
tns:limit (in tns:limitations) |
|
|||||||||||
tns:limitations (in tns:stringPolicy) |
|
|||||||||||
tns:locality (type xsd:string) | Primary locality of the user, the place where
the user usually works, the contry, city or
building that
he
belongs to.
|
|||||||||||
tns:localizedMessage (type tns:LocalizedMessageType) |
|
|||||||||||
tns:lockAfterExpiration (in tns:lifetime) | Number of days after password after password
expiration the account will be locked (0 means never
will be
locked)
|
|||||||||||
tns:logging (in tns:systemConfiguration) | Persistent configuration of logging levels, categories, etc.
|
|||||||||||
tns:maxFileSize (type xsd:string) |
|
|||||||||||
tns:maxHistory (type xsd:int) |
|
|||||||||||
tns:maxLength (in tns:limitations) |
|
|||||||||||
tns:maxOccurs (in tns:limit) |
|
|||||||||||
tns:maxSize (type xsd:int) | The maximum number of entries returned.
|
|||||||||||
tns:message (type xsd:string) | Error or warning message.
|
|||||||||||
tns:messageCode (type xsd:string) |
|
|||||||||||
tns:minLength (in tns:limitations) |
|
|||||||||||
tns:minOccurs (in tns:limit) |
|
|||||||||||
tns:minPasswordAge (in tns:lifetime) | Number of days before password may be changed (0
means password can be changed immediately)
|
|||||||||||
tns:minUniqueChars (in tns:limitations) |
|
|||||||||||
tns:modification |
|
|||||||||||
tns:mustBeFirst (in tns:limit) |
|
|||||||||||
tns:name | Human-readable name for object, property, attribute or whatever.
|
|||||||||||
tns:name (in tns:argument in tns:script) | Argument name.
|
|||||||||||
tns:namespace (type xsd:anyURI) |
|
|||||||||||
tns:nativeCapabilities (type tns:CapabilitiesType) | The capabilities nativelly supported by the connector without any simulation or any
other workaround.
|
|||||||||||
tns:node (in tns:task) | Identifier of the node that has claimed this task.
|
|||||||||||
tns:not |
|
|||||||||||
tns:object |
|
|||||||||||
tns:object (type tns:ObjectType) |
|
|||||||||||
tns:object (type tns:ResourceObjectShadowType) |
|
|||||||||||
tns:objectChange (type tns:ObjectChangeType) | Description of changes that happened to an
resource
object shadow.
|
|||||||||||
tns:objectClass (type xsd:QName) |
|
|||||||||||
tns:objectModification |
|
|||||||||||
tns:objectModification (type tns:ObjectModificationType) |
|
|||||||||||
tns:objectRef |
|
|||||||||||
tns:objectRef (type tns:ObjectReferenceType) |
|
|||||||||||
tns:objects |
|
|||||||||||
tns:objectType (in tns:genericObject) | Type of the stored object.
|
|||||||||||
tns:offset (type xsd:int) | The index of the first returned entry, starting
with zero.
|
|||||||||||
tns:oid (type xsd:string) |
|
|||||||||||
tns:operation (in tns:script) | Defines a set of operations for which the script
should
be executed.
|
|||||||||||
tns:operation (type xsd:string) |
|
|||||||||||
tns:operationResult |
|
|||||||||||
tns:or |
|
|||||||||||
tns:order (in tns:script) | Defines the order in which a script is executed.
|
|||||||||||
tns:orderBy (type tns:PropertyReferenceType) | Property by which the results should be sorted.
|
|||||||||||
tns:orderDirection (type tns:OrderDirectionType) | Direction of ordering (ascending or descending).
|
|||||||||||
tns:organizationalUnit (type xsd:string) | Name or (preferrably) immutable identifier of
organizational unit that the user belongs to.
|
|||||||||||
tns:outbound (in tns:attribute in tns:accountType) | Defines how the attribute value is constructed
in
case of information flow from IDM to the
resource,
e.g. in
case of
provisioning.
|
|||||||||||
tns:outboundPassword (in tns:credentials in tns:accountType) | If true then the passowrd of the
resource
account will be automatically
changed when user
password is
changed.
|
|||||||||||
tns:overwrite (type xsd:boolean) | If set to a true value it will cause that objects that are already in the repository will be
overwritten by the imported objects.
|
|||||||||||
tns:package (in tns:classLogger) | TODO: packages are OR-ed
TODO: string, wildcards
allowed (* as in java)
|
|||||||||||
tns:params (type tns:ParamsType) |
|
|||||||||||
tns:partialResults (type tns:OperationResultType) |
|
|||||||||||
tns:password (defined in tns:CredentialsType complexType) |
|
|||||||||||
tns:passwordHistoryLength (in tns:lifetime) | Number of unique passwords in history (0 - no
history)
|
|||||||||||
tns:passwordPolicy |
|
|||||||||||
tns:path | XPath expression selecting the property container.
|
|||||||||||
tns:pattern (in tns:appender in tns:logging) |
|
|||||||||||
tns:port (type xsd:string) | Port number of the remote service.
|
|||||||||||
tns:present |
|
|||||||||||
tns:progress (in tns:task) | Relative metric of task progress.
|
|||||||||||
tns:property | XPath expression selecting the property.
|
|||||||||||
tns:property (type tns:PropertyReferenceType) |
|
|||||||||||
tns:propertyConstruction (type tns:PropertyConstructionType) | Defines how any of the User's properties
should
be constructed.
|
|||||||||||
tns:propertyModification |
|
|||||||||||
tns:protectedString (in tns:password) |
|
|||||||||||
tns:query |
|
|||||||||||
tns:randomPasswordLength (in tns:credentials in tns:accountType) | If set to any value, the password will be
randomly generated when a new account
is created
and the
password cannot be
determined otherwise.
|
|||||||||||
tns:reaction (in tns:synchronization) | Reaction to a synchronization situation. | |||||||||||
tns:recurrence (in tns:task) | TODO
|
|||||||||||
tns:ref (type xsd:QName) | QName of the XML node that the expression is
supposed to produce.
|
|||||||||||
tns:referentialIntegrity (type xsd:boolean) | If set to true the importe errors will be summarized in the result.
|
|||||||||||
tns:resource |
|
|||||||||||
tns:resource (type tns:ResourceType) |
|
|||||||||||
tns:resourceObjectShadow |
|
|||||||||||
tns:resourceRef (type tns:ObjectReferenceType) |
|
|||||||||||
tns:result (in tns:task) | OperationResult that is used to compile task results (parent result).
|
|||||||||||
tns:retrievalTimestamp (in tns:cachingMetadata) | The timestamp of a time moment when the object was retrieved from the source.
|
|||||||||||
tns:role |
|
|||||||||||
tns:rootLoggerAppender (in tns:logging) |
|
|||||||||||
tns:rootLoggerLevel (in tns:logging) |
|
|||||||||||
tns:schedule (in tns:task) | Task schedule.
|
|||||||||||
tns:schema |
|
|||||||||||
tns:schemaHandling |
|
|||||||||||
tns:script (in tns:scripts) | Specific script definition.
|
|||||||||||
tns:scripts |
|
|||||||||||
tns:serialNumber (in tns:cachingMetadata) | A string that uniquely represents the version of the data that was retrieved.
|
|||||||||||
tns:shadow (type tns:ResourceObjectShadowType) | Resource object shadow as seen by the component
before the
change, if possible.
|
|||||||||||
tns:sharedSecret (type xsd:string) | Shared secret used to authenticate client to the host.
|
|||||||||||
tns:situation (in tns:reaction) | Defines a particular synchronization
situation.
|
|||||||||||
tns:source (in tns:inbound) | Source of assignement.
|
|||||||||||
tns:sourceChannel (type xsd:anyURI) | Definition of source channel (e.g.
synchronization,
reconciliation, discovery, ...)
|
|||||||||||
tns:status (type tns:OperationResultStatusType) |
|
|||||||||||
tns:stopAfterErrors (type xsd:int) | Number of errors that will cause import to stop.
|
|||||||||||
tns:stringPolicy (in tns:passwordPolicy) |
|
|||||||||||
tns:substring |
|
|||||||||||
tns:subSystemLogger (in tns:logging) |
|
|||||||||||
tns:summarizeErrors (type xsd:boolean) | If set to true the importe errors will be summarized in the result.
|
|||||||||||
tns:summarizeSucceses (type xsd:boolean) | If set to true the successfuly imported items will be summarized in the result.
|
|||||||||||
tns:synchronization |
|
|||||||||||
tns:systemConfiguration |
|
|||||||||||
tns:target (in tns:assignment) | TODO: target
|
|||||||||||
tns:target (in tns:inbound) | Destination of the assignment.
|
|||||||||||
tns:targetRef (in tns:assignment) | TODO: target ref
|
|||||||||||
tns:targetSystemType (type xsd:anyURI) | Identification of the kind of target system
that the connector can connect to, such as "LDAP" or "DB Table".
|
|||||||||||
tns:task |
|
|||||||||||
tns:telephoneNumber (type xsd:string) | Primary telephone number of the user.
|
|||||||||||
tns:timeout (type xsd:int) | Timeout (in milliseconds) used when initially
connecting to the
host or during other connections when
timeout
is not
otherwise specified.
|
|||||||||||
tns:token (type xsd:long) |
|
|||||||||||
tns:toString (in tns:unknownJavaObject) |
|
|||||||||||
tns:true |
|
|||||||||||
tns:type |
|
|||||||||||
tns:type (type xsd:string) |
|
|||||||||||
tns:typeExpression (type tns:ExpressionType) |
|
|||||||||||
tns:unknownJavaObject |
|
|||||||||||
tns:user |
|
|||||||||||
tns:user (type tns:UserType) |
|
|||||||||||
tns:userTemplate |
|
|||||||||||
tns:validateDynamicSchema (type xsd:boolean) | If set to true the importe errors will be summarized in the result.
|
|||||||||||
tns:validateStaticSchema (type xsd:boolean) | If set to true the importe errors will be summarized in the result.
|
|||||||||||
tns:validFrom (in tns:activation) | A date from which is should the object be considered active.
|
|||||||||||
tns:validTo (in tns:activation) | A date to which is should the object be considered active.
|
|||||||||||
tns:value (defined in tns:ValueConstructionType complexType) | Static value for the attribute or property. | |||||||||||
tns:value (in tns:equal) |
|
|||||||||||
tns:value (in tns:propertyModification) |
|
|||||||||||
tns:value (type xsd:anyType) | The elements and values of queried
properties.
|
|||||||||||
tns:value (type xsd:string) |
|
|||||||||||
tns:valueConstruction (in tns:propertyConstruction) | Reference (QName) of the property which value
is
defined by this type.
|
|||||||||||
tns:valueExpression (type tns:ExpressionType) |
|
|||||||||||
tns:valueFilter |
|
|||||||||||
tns:variable (type tns:VariableDefinitionType) | Definition of additional variables that should
be
present during evaluation of the expression.
|
|||||||||||
tns:warnBeforeExpiration (in tns:lifetime) | Number of days before password expiration to
send warnings (0 means no warnings)
|
Complex Type Summary | ||||||||||||
|
||||||||||||
Account object type.
|
||||||||||||
Type that defines activation properties.
|
||||||||||||
Contains free form loging configuration.
|
||||||||||||
Configuration of the logger: the facility that collects log messages from the code. | ||||||||||||
Generic assignments of one object to another object.
|
||||||||||||
Description of the attribute handling, such as display name, read/write access and value and synchronization expressions. | ||||||||||||
Metadata that record when a cache copy was retrieved, the identifiers (etags) of that
copy and possibly also other data.
|
||||||||||||
TODO
|
||||||||||||
Definition of valid characters in class.
|
||||||||||||
Configuration of the logger: the facility that
collects log
messages from the code.
|
||||||||||||
Host definition for remote connector, remote
connector framework or a remote "gateway".
|
||||||||||||
Description of a generic connector.
|
||||||||||||
This is a container type for various credentials types: passwords, public keys, one-time password
scheme identifiers, etc.
|
||||||||||||
Type that contains nothing.
|
||||||||||||
|
||||||||||||
|
||||||||||||
The expression code is supposed to be in the contect of this type.
|
||||||||||||
Generic expression.
|
||||||||||||
Object with generic extensibility mechanism.
|
||||||||||||
|
||||||||||||
|
||||||||||||
Generic object for storing unknown (unexpected) object types.
|
||||||||||||
The options for import tasks.
|
||||||||||||
Definition of complexity and string policy
|
||||||||||||
|
||||||||||||
Configuration of logging levels, categories, log
files, etc.
|
||||||||||||
|
||||||||||||
|
||||||||||||
Describes object addition (creation, operation
"add").
|
||||||||||||
Describes object deletion (operation "delete").
|
||||||||||||
Describes object modification (operation
"modify").
|
||||||||||||
Describes a change of a specific object.
|
||||||||||||
|
||||||||||||
Describes a change of attributes of a specific
object.
|
||||||||||||
Reference to an object.
|
||||||||||||
Common supertype for all identity objects.
|
||||||||||||
TODO
|
||||||||||||
Parameters limiting the number of returned
entries, offset, etc.
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
TODO
|
||||||||||||
Describe available or proposed values of an attribute. | ||||||||||||
|
||||||||||||
Definition of construction of a (general)
property.
|
||||||||||||
Property container reference.
|
||||||||||||
Describe a change to a single attribute. | ||||||||||||
|
||||||||||||
TODO
|
||||||||||||
Property reference.
|
||||||||||||
|
||||||||||||
ONLY COPIED AND PASTED FROM ProtectedStringType, please update if needed later
TODO
|
||||||||||||
This is a general-purpose type to store sensitive values that should be encrypted in
the repository.
|
||||||||||||
TODO
Experimental object.
|
||||||||||||
TODO
|
||||||||||||
|
||||||||||||
Describes a change of a specific resource object
together with
definitions of the source.
|
||||||||||||
|
||||||||||||
Local copy of any object on the provisioning
resource that
is related to provisioning.
|
||||||||||||
|
||||||||||||
Resource represents a system or component external
to the IDM
system which we manage.
|
||||||||||||
A role that implies assignments.
|
||||||||||||
Task schedule.
|
||||||||||||
Specification of handling details for resource
schema.
|
||||||||||||
Script argument.
|
||||||||||||
Collection of scripts to be executed for various
provisioning
operations.
|
||||||||||||
Specifies how and when a script is executed during
provisioning.
|
||||||||||||
Definition of valid single string limitation
|
||||||||||||
|
||||||||||||
Configuration of the logger: the facility that
collects log messages from subsystem code.
|
||||||||||||
Defines a synchronization properties
(configuration) for a
resource.
|
||||||||||||
System configuration object.
|
||||||||||||
TODO
|
||||||||||||
|
||||||||||||
Type used to represent Java objects that are otherwise unknown to the system and cannot be
represented in "canonical" XML form.
|
||||||||||||
|
||||||||||||
|
||||||||||||
The user template used to create new users.
|
||||||||||||
User object type.
|
||||||||||||
Defines an assignment of value from one place (or
expression) to
another place.
|
||||||||||||
Defines how a value of a property (or attribute)
should be
constructed.
|
||||||||||||
Defines value filter. | ||||||||||||
Definition of a variable. | ||||||||||||
This element contains the XSD-formatted definition of schema. | ||||||||||||
Defines a type for XPath pointer.
|
Simple Type Summary | ||||||
TODO
|
||||||
TODO
|
||||||
TODO
|
||||||
TODO
|
||||||
Type of an operation (change).
|
||||||
Type of an operation (change).
|
||||||
TODO
The "TypeType" in the name is correct.
|
||||||
An enumeration that defines where the script will
be excuted.
|
||||||
An enumeration that defines when the script will
be excuted.
|
||||||
TODO
|
||||||
OID constants for system objects
|
||||||
TODO
|
||||||
Exclusivity status tells about task "locking" to a particular node.
|
||||||
Execution status provides information about the task overall high-level execution state.
|
||||||
TODO
|
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) 2011 Evolveum --> <!-- --> <!-- The contents of this file are subject to the terms --> <!-- of the Common Development and Distribution License --> <!-- (the License). You may not use this file except in --> <!-- compliance with the License. --> <!-- --> <!-- You can obtain a copy of the License at --> <!-- http://www.opensource.org/licenses/cddl1 or --> <!-- CDDLv1.0.txt file in the source code distribution. --> <!-- See the License for the specific language governing --> <!-- permission and limitations under the License. --> <!-- --> <!-- If applicable, add the following below the CDDL Header, --> <!-- with the fields enclosed by brackets [] replaced by --> <!-- your own identifying information: --> <!-- --> <!-- Portions Copyrighted 2011 [name of copyright owner] --> <!-- --> <!-- Portions Copyrighted 2010-2011 ForgeRock, Inc. --> <xsd:schema elementFormDefault="qualified" jaxb:extensionBindingPrefixes="xjc" jaxb:version="2.0" targetNamespace="http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd" xmlns:a="http://midpoint.evolveum.com/xml/ns/public/common/annotation-1.xsd" xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" xmlns:tns="http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:annotation> <xsd:documentation> This is a common schema for midPoint project. It contains all the data types that the stock midPoint is using. This file contains more that a common schema in fact. It contains all the objects, even parts of what is known as identity schema and model schema in midPoint. See https://wiki.evolveum.com/display/midPoint/Data+Model for more details. </xsd:documentation> <xsd:appinfo> <jaxb:globalBindings> <xjc:typeSubstitution type="complex"/> <xjc:serializable uid="201105211233"/> </jaxb:globalBindings> </xsd:appinfo> </xsd:annotation> <xsd:import namespace="http://www.w3.org/2001/XMLSchema" schemaLocation="../../standard/XMLSchema.xsd"> <xsd:annotation> <xsd:documentation> Importing the schema of XSD schema definition explicitly. This causes that we can use "strict" matching for the xsd:schema elements used in runtime. </xsd:documentation> </xsd:annotation> </xsd:import> <xsd:import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="../../standard/xenc-schema.xsd"> <xsd:annotation> <xsd:documentation> The XML Encryption schema. Used for "protected" data types (property encryption). </xsd:documentation> </xsd:annotation> </xsd:import> <xsd:import namespace="http://midpoint.evolveum.com/xml/ns/public/common/annotation-1.xsd" schemaLocation="annotation-1.xsd"> <xsd:annotation> <xsd:documentation> Common midPoint annotations used in various XSD schemas. </xsd:documentation> </xsd:annotation> </xsd:import> <!-- ################################## --> <!-- ## Common Schema Layer ## --> <!-- ################################## --> <!-- See https://wiki.evolveum.com/display/midPoint/Common+Schema --> <xsd:annotation> <xsd:documentation> Human-readable name for object, property, attribute or whatever. TODO: Any special reason this is top-level element? </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:appinfo> <jaxb:dom/> </xsd:appinfo> <xsd:documentation> Defines a type for XPath pointer. It points to a specific part of the XML tree. Only a path expressions should be used in this type, as it is used as an l-value, i.e. pointing to a part of XML where an value can be assigned. cf. ExpressionType </xsd:documentation> </xsd:annotation> </xsd:complexType> <!-- Basic Object Types --> <xsd:annotation> <xsd:documentation> Common supertype for all identity objects. Defines basic properties that each object must have to live in our system (identifier, name). Objects consists of identifier and name (see definition below) and a set of properties represented as XML elements in the object's body. The properties are represented as first-level XML elements (tags) of the object XML representation and may be also contained in other tags (e.g. extension, attributes) that are marked by a propertyContainer annotation. The QName (namespace and local name) of the element holding the property is considered to be a property name. Single-value properties must appear as a none or one instance of the XML element holding the value. Multi-value properties must appear as none or more instances of the same XML element. Multi-valued properties are regarded as unordered sets. Duplicate values are allowed, but duplicates should not be preserved by the implementations. The implementations should reduce duplicate values to a single value if it is possible and efficient. If an element for a specific property does not appear in the object it means that the property value is undefined (property does not exists). This is a different state as compared to passing an empty XML element. Empty XML element means that the property exists, but has an empty (null) value. Implementations must be able to handle undefined (non-existent) properties, but may NOT be able to handle empty (null) values. The use of empty (null) values is DISCOURADGED. It is not mandated by this specification how to pass ordered lists and multi-value properties with duplicates. However it is recommended to use single value properties with appropriate complex XML data structures to hold such data. The following XML snippet is an example of the object (omitting namespace definitions, but assuming default namespace to be the target namespace of this schema definition): <![CDATA[ <user oid="d3adm3a4" version="42"> <name>foobar</name> <extension> <foo:geekName>F00 B4r</foo:geekName> <org:guild>Societus Geekus Europeus</org:guild> <org:guild>Basset User Group</org:guild> <pet:pet><pet:species>dog</pet:species><pet:breed>basset</pet:breed><pet:name>Doggie</pet:name></pet:pet> <pet:pet><pet:species>mouse</pet:species><pet:breed>logitech</pet:breed><pet:name>Mousee</pet:name></pet:pet> <com:shoppingPreferences> <com:tShirt><com:size>XXL</com:size><com:color>#000000</com:color></com:tShirt> <com:tie><com:preference>no thanks</com:preference></com:tie> </com:shoppingPreferences> </extension> <fullName>Foo Bar</fullName> <givenName>Foo</givenName> <familyName>Bar</familyName> </user> ]]> The above example describes an object with identifier "d3adm3a4", name "foobar" and type defined by its top-level element User that corresponds to URI "http://midpoint.evolveum.com/xml/ns/identity/1#User". The object has 7 properties. Three of them are standard properties defined by this schema: Standard properties "fullName", "givenName" and "familyName" in default namespace. These are single-valued string properties. All the other properties are non-standard "extended" properties, but they are considered equal to the standard attributes. They are quarantined in the <extension> tag only to avoid XSD unique particle attribution (UPA) problems. In the above example the non-standard properties are: Property "geekName" in namespace defined by "foo" prefix. This is also single-valued string property. Multi-valued non-standard property "guild". It is a string property with multiple values. Multiple values are represented by providing multiple instances of XML elements in the document. Such properties are typically used for roles, groups, etc. Complex property "pet". This property is defined by complex XML type, using XML sub-elements to represent structured data. Note that the use of XML attributes is discouraged in the properties, although it might be possible in some cases. This is also multi-valued property. Complex property "shoppingPreferences". This property is using complex XML type to form a structure of XML elements to represent data. This is a single-valued property. Note that the sub-elements "tShirt" and "tie" are NOT considered to be properties. QName-URI mapping: For the purpose of this schema and all components that are using it, URIs and QNames are considered equivalent. This is required by WWW architecture and also helps avoid some drawbacks and bugs in XML-related implementations that usually do not deal QNames well. The QNames are mapped to URIs by concatenating namespace URI and a local name. If URI does not end with slash (/) or hash (#) character, slash is concatenated to the URI before adding the local name. The URI-QName mapping is the reverse process. </xsd:documentation> <xsd:appinfo> <a:propertyContainer/> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Human-readable, mutable name of the object. It may also be an identifier (login name, group name). Should be unique in the respective context of interpretation. E.g. the name of the UserType subtype should be unique in the whole system. The name of the AccountType subtype should be unique in the scope of resource (target system) that it belongs to. This may not be human-readable in a sense to display to a common end-user. It is intended to be displayed to IDM system administrator. Therefore it may contain quite a "ugly" structures such as LDAP DN or URL. Name is considered to be ordinary property of the object. Therefore it can be changed by invoking usual modifyObject operations. However, change of the name may have side effects (rename process). Although name is specified as optional by this schema, it is in fact mandatory for most object types. The reason for specifying the name as optional is that the name may be generated by the system instead of supplied by the clients. However, all objects stored in the repository must have a name. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Free-form textual description of the object. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:annotation> <xsd:documentation> System-wide immutable identifier for the object. Will be probably quite long and not human-readable. It should not be displayed to user. It has no meaning outside of IDM system and should not be directly passed to any third-party systems. This identifier must be unique in the entire system. This attribute is immutable. It cannot be changed. Any operation attempting to change this identifier must fail. OID is not property and therefore cannot be "addressed" in usual operations. OID must be provided for all objects that are persistently stored. There may be detached objects without OID. Such objects have the same structure as normal objects, they are just not stored in the repository. E.g. object that are only stored on resource and are not replicated in the repository. Such objects do not have OID therefore their XML representation cannot contain oid attribute. The OID should be unique in both time and space. That means that OIDs must be unique in the whole system in any moment and should not be re-used. If an object is deleted, the OID of that object should not be used by a new object. The reason is to avoid problems with stale links pointing to a wrong object and appearing valid. However, this is not a strict requirement. Some marginal probability of OID reuse is tolerated. The recommended practice is to add some randomness to the process of OID generation. This attribute is NOT (necessarily) ASN.1 OID and should not be confused with it. The attribute is named "oid" meaning object identifier. It is not named "id" to avoid confusion with xml:id attribute as it is easy to confuse these two if namespace prefix is omitted. The confusion with ASN.1 OID id not likely. The oid is XML attribute of this object instead of element because it has special purpose of identifying the object. It is also immutable, therefore we do not need to handle changes to it. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> Version for optimistic locking. Contains the version in which this object was read from the repository, fetched from the resource, etc. Type of the version attribute is string, not integer to provide flexibility for various versioning schemes in implementation (e.g. ETags). The type really does not matter, the only things that matters is if the version is the same or different. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <xsd:annotation> <xsd:documentation> Free-form textual description of the object. It is supposed to describe the object or a construct that it is attached to. Anything that the system administrator wants may be here. The system will not interpret the information except for displaying it and allow user to edit it. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Place for non-standard object properties. The elements placed here will be handled exactly like the elements in the object body. It must NOT contain standard elements. </xsd:documentation> <xsd:appinfo> <a:propertyContainer/> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:annotation> <xsd:documentation> Object with generic extensibility mechanism. It contains a special XML element where almost any extension can be placed. The extension is treated exactly the same as other object properties by the code (storage, modifications, etc), except that the system may not be able to understand their meaning. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Generic object for storing unknown (unexpected) object types. The generic object should be used if there is a need to store a custom object (e.g KangarooType) at deployment-time and the XML type relacement extensibility cannot be used. The properties of such custom objects are to be placed in the extension part of this object. The schema is not checked or enforced for this type of objects if technically possible. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Type of the stored object. This attribute contains URI defining the type (class) of stored object. The URI that maps to a QName of an object XML element should be used if possible (see QName mapping above). However this is not mandatory and the implementation must be able to work with any URI. Object type may be changed, but the possible values may be constrained by the implementation. E.g. the implementation may allow to change the object type only to the subtype or supertype, or it may fail if the attributes of the object does not conform to the schema constraints defined for the new type. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Reference to an object. It contains OID of the object that it refers to. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Filter that can be used to dynamically lookup the reference OID e.g. during imports. It must not be used for normal operations and references with the filter must not be stored in the repository. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:annotation> <xsd:documentation> Target of the reference. Optional only during imports. The objects stored in the repository must have the OID value filled in. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> XSD type of the reference target object. It should be provided if the type is known (e.g. when reading object from the repository). The primary reason for this is to have some kind of type safety but especially to be able to use this in the XPaths that specify what references to resolve. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- Property-related types --> <xsd:annotation> <xsd:documentation> Property reference. Selects one or more properties in the object instance documents. Subtypes of property reference describe properties in the object instances. For example by describing change to the property, available values for the property, etc. </xsd:documentation> </xsd:annotation> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> XPath expression selecting the property. It may select multiple properties. But it must not be used to select XML constructs inside a property, unless such property is in itself an object. The root of the path is assumed to be the element of the top-most ObjectType. The path should be absolute, starting with leading slash ("/"). If the leading slash is not present, it should be assumed, but warning message should be logged in such case. Good examples: /fullName /extension/foobar /account/name /account[@oid='1234']/name /account/attribute/ldap:cn Bad examples: /extension/shoppingPreferences/tShirt (tShirt is not property, shoppingPreferences is) /extension (extension is not property, it is rather container of properties) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Property container reference. Selects exactly one XML element that holds properties. Subtypes of property container reference describe properties in the object instances, but they use native reference to the specific property (e.g. QName or XML elements using xsd:any type). For example by describing change to the property, available values for the property, etc. </xsd:documentation> </xsd:annotation> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> XPath expression selecting the property container. It must select exactly one XML element. It must not be used to select XML constructs inside a property, unless such property is in itself an object. The root of the path is assumed to be the element of the top-most ObjectType. Path attribute may be ommited. In that case it is assumed to be "/". The path should be absolute, starting with leading slash ("/"). If the leading slash is not present, it should be assumed, but warning message should be logged in such case. Good examples: / /extension /account[@oid='1234']/attributes Bad examples: /extension/shoppingPreferences this selects a property, not property container /extension/shoppingPreferences/tShirt (tShirt is not property container) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Describe available or proposed values of an attribute. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other"> <xsd:annotation> <xsd:appinfo> <xjc:dom/> </xsd:appinfo> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:annotation> <xsd:documentation> True if property can contain only the values listed in the instance of this type. False is property can contain other values as well. In such case the list of values listed in the instance of this type should be considered only a list of suggested values. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="0" name="availableValues" type="tns:PropertyAvailableValuesType"/> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumClass/> </xsd:appinfo> </xsd:annotation> <xsd:enumeration value="read"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="READ"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="update"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="UPDATE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="create"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="CREATE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> Presence of this element signifies that the strcture that it contains should be ignored. If this element is present in the attribute definition, the attribute should be ignored. If it appears in the object class definition, the entire object class should be ignored. "Ignored" means that the system should pretend that the structure does not exist at all. This element may also be used as XSD annotation in the dynamic schemas. </xsd:documentation> </xsd:annotation> </xsd:element> <!-- Object changes --> <xsd:annotation> <xsd:documentation> Describes a change of attributes of a specific object. All changes are expected to happen atomically, but there may be exceptions. Please check with the documentation of the interface using this type for more details. This should probably go to some kind of common schema. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> OID of the object to modify. Due to consistency reasons this should rather be an attribute. But it is an element because of OpenESB bug with attributes in message parts. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Describe a change to a single attribute of an object. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Describe a change to a single attribute. In this case the path expression used in the "property" attribute must select exactly one property. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:complexType> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax"> <xsd:annotation> <xsd:documentation> The elements and values of changed properties. Multi-valued properties are expressed as usual, that means by repeating the element containing the property value. All the elements must have the same QName and be of the same type. If more than one property is changed, the entire PropertyChangeType element must be repeated. </xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO The "TypeType" in the name is correct. This is the type for "change type" therefore the name is OK although it looks strange. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumClass/> </xsd:appinfo> </xsd:annotation> <xsd:enumeration value="add"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="add"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="replace"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="replace"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="delete"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="delete"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> Describes a change of a specific object. This is abstract type. It cannot be used directly. Use the subtypes instead. </xsd:documentation> </xsd:annotation> </xsd:complexType> <xsd:annotation> <xsd:documentation> Describes object addition (creation, operation "add"). </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Describes object modification (operation "modify"). </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Describes object deletion (operation "delete"). </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> OID of the deleted object. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Describes a change of a specific resource object together with definitions of the source. Note: This is quite an atrificial structure. In fact it should be splint into WSDL message parts instead one XSD type. But the ObjectChangeType is polymorphic and OpenESB has problems with such types if placed directly into message parts. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Description of changes that happened to an resource object shadow. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Definition of source channel (e.g. synchronization, reconciliation, discovery, ...) Should in fact be QName. But OpenESB has problems with QNames. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Resource object shadow as seen by the component before the change, if possible. This object is mandatory. In some cases (e.g. addition) the object may not exist before the change. In such a case the caller is reponsible to create such object in the repository before calling this operation (see the note before). Even thought this object is mandatory, it may not be complete. The content of this object depends on how the change was detected, configuration of a calling component and so on. On the very minimum, the shadow object must contain: * OID * Identifiers necessary to locate the associated resource object on the resource. Note: This is actually the shadow object that was stored in the repository at the time the change was detected (or created at that moment). Note: This was orginally defined as an object before the change and it was option. Such definition does not allow some operations, such as create a user and link account (because the objectChange does not have OID and therefore cannot be linked to). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Resource that was the origin of the change. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Metadata that record when a cache copy was retrieved, the identifiers (etags) of that copy and possibly also other data. It is used to guide cache coherence policies and cache management in general. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> The timestamp of a time moment when the object was retrieved from the source. Used mostly for diagnostics and general visibility. As this is relativelly rough granularity and the time in distributed system is relative anyway, it is not really useful for anything else. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> A string that uniquely represents the version of the data that was retrieved. The objects of the same type and origin with the same serial number are assumed to be the same. There is no requirement for this to be identifier - the serialNumber cannot be used to retrieve the object. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> This is a general-purpose type to store sensitive values that should be encrypted in the repository. It is using starndard XML Encryption schema. </xsd:documentation> </xsd:annotation> <xsd:choice> <!-- <xsd:element name="alias" type="xsd:string" minOccurs="0" /> --> <xsd:annotation> <xsd:documentation> Use of XML Encryption standard EncryptionData element. </xsd:documentation> <!-- <xsd:appinfo> <jaxb:dom /> </xsd:appinfo> --> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Clear text value of the protedted data. It is useful for imports and tests. This element should never appear in repository or any other long-term storage. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:complexType> <xsd:annotation> <xsd:documentation> ONLY COPIED AND PASTED FROM ProtectedStringType, please update if needed later TODO </xsd:documentation> </xsd:annotation> <xsd:choice> <!-- <xsd:element name="alias" type="xsd:string" minOccurs="0" /> --> <xsd:annotation> <xsd:documentation> Use of XML Encryption standard EncryptionData element. </xsd:documentation> <!-- <xsd:appinfo> <jaxb:dom /> </xsd:appinfo> --> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Clear text value of the protedted data. It is useful for imports and tests. This element should never appear in repository or any other long-term storage. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:complexType> <xsd:annotation> <xsd:documentation> Type that contains nothing. Used in WSDL messages that do not return anything to silence the warnings. </xsd:documentation> </xsd:annotation> </xsd:complexType> <!-- Filters & queries --> <xsd:annotation> <xsd:appinfo> <jaxb:dom/> </xsd:appinfo> </xsd:annotation> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:complexContent> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> XPath to the containing XML element for the queried propoerty. If not specified, defatults to "." (which is also the most usual value). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:choice> <xsd:complexType> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax"> <xsd:annotation> <xsd:documentation> The elements and values of queried properties. Multi-valued properties are not allowed here. Use "and" or "or" clauses if needed. </xsd:documentation> <xsd:appinfo> <xjc:dom/> </xsd:appinfo> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:annotation> <xsd:documentation> The expression that can be used to dynamically evaluate the value. It may or may not be used, depending on where is this type used. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> XPath to the property being queried. It is mandatory, as there is no reasonable default as in the case of path. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:choice> <xsd:annotation> <xsd:documentation> The elements and values of queried properties. Multi-valued properties are not allowed here. Use "and" or "or" clauses if needed. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> The expression that can be used to dynamically evaluate the value. It may or may not be used, depending on where is this type used. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexContent> <xsd:sequence> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="equal" substitutionGroup="tns:filter" type="tns:PropertyComplexValueFilterType"/> <xsd:element name="greaterOrEqual" substitutionGroup="tns:filter" type="tns:PropertySimpleValueFilterType"/> <xsd:element name="lessOrEqual" substitutionGroup="tns:filter" type="tns:PropertySimpleValueFilterType"/> <!-- Following element should be constrained a bit more, because their value is always string respectively. But we don't know how to constrain it now and we do not have the time to find out. Therefore it should be OK for now. --> <xsd:element name="substring" substitutionGroup="tns:filter" type="tns:PropertySimpleValueFilterType"/> <xsd:complexContent> </xsd:complexContent> </xsd:complexType> <xsd:complexContent> <xsd:sequence> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexContent> <xsd:sequence> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Parameters limiting the number of returned entries, offset, etc. Used in the web service operations such as list or search </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Property by which the results should be sorted. Reference to a property (XPath). Just one property for now. Maybe we will change this to a list later. If not specified, the ordering is arbitrary. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Direction of ordering (ascending or descending). Only valid if "orderBy" element is specified. If not specified, the ordering order is ascending. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> The index of the first returned entry, starting with zero. Therefore if 0 is specified, the resulting list will start with first entry. If 1 is specified, the resulting set will start with second entry. If not specified, value of zero (0) is assumed. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> The maximum number of entries returned. The operation may return specified number of number of entries or less. If not specified, unlimited maximum size is assumed. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Type of an operation (change). It defines operations to change object, it is not limited to object modifications. TODO: How to handle renames? </xsd:documentation> </xsd:annotation> <xsd:enumeration value="ascending"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="ASCENDING"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="descending"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="DESCENDING"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> The options for import tasks. It specifies optional settings for import such as "overwrite" and "stop on error". </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> If set to a true value it will cause that objects that are already in the repository will be overwritten by the imported objects. It may not be applicable to all import types. E.g. it makes no sense for import from resource, as this is not storing objects in the repository directly. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to a true value it will cause that objects that overwritten objects will reuse the same OID as previous objects. May be potentially dangerous. USE WITH CARE. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Number of errors that will cause import to stop. If set to one the import will stop on first error. If set to zero or negative value the import will not stop on any error. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to true the successfuly imported items will be summarized in the result. WARNING: setting this to false may result in a very large result structure and may cause overflow of the system memory. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to true the importe errors will be summarized in the result. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to true the importe errors will be summarized in the result. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to true the importe errors will be summarized in the result. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to true the importe errors will be summarized in the result. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to true the importe errors will be summarized in the result. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to true the importe errors will be summarized in the result. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Execution status provides information about the task overall high-level execution state. It tells whether the task is running/runnable, waits for something or is done. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Exclusivity status tells about task "locking" to a particular node. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Identifier of the node that has claimed this task. Should be only present if excelusivity status is "claimed". </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Expiration of the claim. If a "claimed" task is found after the moment specified in this attribute, the task is no longer considered claimed. Should be only present if excelusivity status is "claimed". </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Handler URI indirectly specifies which class is responsible to handle the task. The handler will execute reaction to a task lifecycle events such as executing the task, task heartbeat, etc. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> OperationResult that is used to compile task results (parent result). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Object that the task is associated with. Tasks may be associated with a particular objects. For example a "import from resource" task is associated with the resource definition object that it imports from. Similarly for synchronization and reconciliation tasks (cycles). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Relative metric of task progress. TODO </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO loose - tight If not present the nodes may decide independently. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Task schedule. Specifies when and how often to execute the task. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Execution status provides information about the task overall high-level execution state. It tells whether the task is running/runnable, waits for something or is done. </xsd:documentation> </xsd:annotation> <xsd:enumeration value="running"> <xsd:annotation> <xsd:documentation> The task is running or is ready to be executed. This state implies that the task is being actively executed by IDM nodes, e.g. there is a thread on one of the IDM nodes that executes the task or the system needs to allocate such thread. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="RUNNING"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="waiting"> <xsd:annotation> <xsd:documentation> The IDM system is waiting while the task is being executed on an external node (e.g. external workflow engine) or is waiting for some kind of external signal (e.g. approval in internal workflow). The task may be running on external node or blocked on IDM node. One way or another, there is no point in allocating a thread to run this task. Other task properties provide more information about the actual "business" state of the task. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="WAITING"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="closed"> <xsd:annotation> <xsd:documentation> The task is done. No other changes or progress will happen. The task in this state is considered immutable and the only things that can happen to it is a delete by a cleanup code. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="CLOSED"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> Exclusivity status tells about task "locking" to a particular node. </xsd:documentation> </xsd:annotation> <xsd:enumeration value="claimed"> <xsd:annotation> <xsd:documentation> The tasks is being held by one of the IDM nodes. The node is either executing the task or making some kind of "exclusive" operation on the task. Only one node may "claim" a task. Claimed tasks has an allocated *thread* that is used for task execution. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="CLAIMED"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="released"> <xsd:annotation> <xsd:documentation> The task is free for all nodes to participate. Any node may try to "claim" the task to execute it or make another step in the task lifecycle. Released task is not being executed by an IDM node and therefore does not have an allocated thread. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="RELEASED"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:enumeration value="single"> <xsd:annotation> <xsd:documentation> TODO The task is executed only once, at the first moment that the scedule specifies. If that moment is in the past, the task will be executed as soon as any execution environment (node) is available. Once the task is finished, it will not be executed again. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="SINGLE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="recurring"> <xsd:annotation> <xsd:documentation> TODO The task is executed as many times as the schedule specifies. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="RECURRING"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:enumeration value="loose"> <xsd:annotation> <xsd:documentation> The task is claimed (exclusivelly locked) to a specific node only if it is executing. The thread is allocated only for the minimal amount of time. It does not matter which node will execute the task as long as there is an appropriate handler. This is efficient for tasks that take long time to execute and the execution mostly waits (e.g. approvals) or for tasks which have long interval between executions (e.g. reconciliation). </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="LOOSE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="tight"> <xsd:annotation> <xsd:documentation> Task is claimed (exclusivelly locked) to a specific node for a long time. It may be claimed until the executing node is up and running. A theread may be running and allocated for the task all the time. The thread may to to sleep as needed, but during that time the task remains claimed. The node that started to execute this task will be preferred for subsequent executions. This is efficient for recurring tasks executed in short intervals, such as live synchronization. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="TIGHT"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> Task schedule. Specifies when and how often something should happen. UNSTABLE. This type will most likely change. A lot. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Interval in seconds between task invocations. UNSTABLE. This element will most likely change. A lot. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <!-- Following types SHOULD NOT be here. They should be in the respository WSDL definition. However, there is a bug in OpenESB (OPENESB-5) and placing the elements to this namespace works around that bug. This should be moved to the WSDL once the bug is resolved. --> <xsd:sequence> </xsd:sequence> </xsd:complexType> <!-- ################################## --> <!-- ## Identity Schema Layer ## --> <!-- ################################## --> <!-- The following clauses belong to the identity schema layer. This schema defines the "identity model", the basic objects for midPoint system that are common for most IDM deployments. It is supposed to be heavily used by midPoint low-level components and also by business logic. See https://wiki.evolveum.com/display/midPoint/Identity+Schema --> <xsd:annotation> <xsd:documentation> User object type. Represents physical user of the system. TODO: More details Inspired by FOAF, but still quite LDAP-ish. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Full name of the user with all the decorations, middle name initials, honorific title and any other structure that is usual in the cultural environment that the system operates in. This element is intended to be displayed to a common user of the system. Examples: cpt. Jack Sparrow, William "Bootstrap" Turner, James W. Random, PhD., Chuck Norris </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Given name of the user. It is usually the first name of the user, but the order of names may differ in various cultural environments. This element will always contain the name that was given to the user at birth or was chosen by the user. Examples: Jack, Chuck </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Family name of the user. It is usually the last name of the user, but the order of names may differ in various cultural environments. This element will always contain the name that was inherited from the family or was assigned to a user by some other means. Examples: Sparrow, Norris </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Middle name, nick name or any other names of a person. Examples: "Bootstrap", Walker Multi-valued property. Please note that the order of additional names may not be preserved. If the order is important, the use a single value with all the names concatenated as appropriate. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Honorific titles that go before the name. Examples: cpt., Ing., Sir This property is single-valued. If more than one title is applicable, they have to be represented in a single string (concatenated) form in the correct order. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Honorific titles that go after the name. Examples: PhD., KBE This property is single-valued. If more than one title is applicable, they have to be represented in a single string (concatenated) form in the correct order. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> E-Mail address of the user. This is the address supposed to be used for communication with the user. E.g. IDM system may send notifications to the e-mail address. It is NOT supposed to be full-featured e-mail address data structure e.g. for the purpose of comlex address-book application. This is mult-valued property. In case more than one e-mail address is specified, the same message should be sent to all the addresses. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Primary telephone number of the user. This is multi-valued attribute. In case more than one telephone number is specified, all telephone numbers are considered equivalent. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Unique, business-oriented identifier of the employee. Typically used as correlation identifier and for auditing purposes. Should be immutable, but the specefic properties and usage are deployment-specific. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Employee type specification such as internal employee, external or partner. The specific values are deployment-specific. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Name or (preferrably) immutable identifier of organizational unit that the user belongs to. The format is deployment-specific. This is multi-valued property to allow membership of a user to several organizational units. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Primary locality of the user, the place where the user usually works, the contry, city or building that he belongs to. The specific meaning and form of this property is deployment-specific. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> The set of user's credentials (such as passwords). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> User's activation. e.g. enable/disable status, start and end dates, etc. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Set of user's assignments. Represents objects (such as roles) or accounts directly assigned to a user. </xsd:documentation> </xsd:annotation> </xsd:element> <!-- xsd:choice minOccurs="0" maxOccurs="unbounded" --> <xsd:annotation> <xsd:documentation> Set of user's accounts. This is the set of accounts that belongs to the user in a sense that these accounts represents the user (the same physical person, they are analogous). This element contains full AccountType XML elements. This version will probably be used in workflows and business logic. If this attribute is present in the User object, the accountRef attribute for the same account OID must not be present. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Set of user's accounts. This is the set of accounts that belongs to the user in a sense that these accounts represents the user (the same physical person, they are analogous). This element contains a set of pointers to Account objects (by OID) this version will be used in repository (for storage). If this attribute is present in the User object, the account attribute for the same account OID must not be present. </xsd:documentation> </xsd:annotation> </xsd:element> <!-- /xsd:choice --> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> This is a container type for various credentials types: passwords, public keys, one-time password scheme identifiers, etc. However, we expect that password will be the most widely used credential type and that's actually also the only supported type. The reason to "formalize" this structure is the ability to synchronize credentials. If the password would be just an ordinary attribute, we cannot automatically synchronize user and account passwords. Similarly as other credential types. Note: marking password with a special attribute type will not be enough. There may be numerous passwords with various meanings, we need to distinguish the "primary" one to synchronize. We also need to store user password somewhere. This is not perfect. It may change in the future. TODO: support for "old password", e.g. some resource need it to change password. </xsd:documentation> <xsd:appinfo> <a:propertyContainer/> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:complexType> <xsd:sequence> <xsd:annotation> <xsd:documentation> The number of failed logins. It should be increased after every unsuccessful use of the credential. It may be reset after successful login or a time-out or may not. It depends on the policy setting. If not present, value of zero (0) is assumed. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> The date and time of last failed login attempt. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <!-- More credentail types may be here, such as OTP seeds, X.509 credentials, etc. --> <xsd:annotation> <xsd:documentation> If true, the user will have access to the IDM GUI. The access will provide access to all functions, therefore this is kind of "superuser" flag. This is a temporary solution until we implement fully-featured authorization mechanism. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Generic assignments of one object to another object. This will usually be assignment of a role to a user, assignment of an organizational unit, team or whatever. It may also be used to assing role to another role, creating a role hierarchy. Assignment is an abstract concept. It can be anything that gives the "receptor" object additional access rights, privileges, capabilities or similar ability or right. But it may also constraint the object with policy, e.g. to impelemt separation of duties. Roles, organizations and privileges in IDM system are examples of assignments. The assignemtn may target either existing IDM object (such as a role) or abstract resource account that may or may not exist. In case of resource objects it is constrained to accounts, as accoutns are the only resource objects that can be assigned to a user. Other resource objects (entitlements) can be assigned to accounts, but not to users. TODO: constraints </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:choice> <xsd:annotation> <xsd:documentation> TODO: target </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO: target ref </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Type that defines activation properties. Determines whether something is active (and working) or inactive (e.g. disabled). It applies to several object types. It may apply to user, account, assignement, etc. The data in this type define if the described concept is active, from when it is active and until when. The "active" means that it works. If something is not active, it should not work or not cause any effect. E.g. inactive user should not be able to log in or run any tasks, the non-active role should not be assigned and if assigned it should not be taken into account when computing the accounts. </xsd:documentation> <xsd:appinfo> <a:propertyContainer/> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Flag that indicates if the described concept is active. true => active, enabled flase => inactive, disabled This defines the "administrative state", i.e. the administrator's decision. If set, this flag overrides any other constraints in the activation type. E.g. if this is set to true and the object is not yet valid (according to validFrom below), the user should be considered active. If set to false the user should be considered inactive regardless of other settings. Therefore this flag does NOT define an actual state of the object. It is a kind of "manual override". If this flag is not present then the other constraints in the activation type should be considered. If not present and there are no other constraints in the activation type or if there is no activation type at all then the values is assumed to be true, i.e. that the described concept is active (enabled). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> A date from which is should the object be considered active. Not applied if the "enabled" flag is set to any value. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> A date to which is should the object be considered active. Not applied if the "enabled" flag is set to any value. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Resource represents a system or component external to the IDM system which we manage. It is sometimes called _IT resource_, _target system_, _source system_, _provisioning target_, etc. IDM system connects to it to create accounts, assign accounts to groups, etc. But it also may be an authoritative source of data, system that maintains lookup tables, database that contains organizational structure, etc. The {{Resource}} will most likely provide a combination of several functions (e.g. both provisioning and authoritative data for some attributes). </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> "Composite" version of the ConnectorType reference. See below for more details. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Reference to the connector that implements specified resource. Connector reference is MANDATORY. Although the schema does not enforce it (due to various JAXB reasons), exactly one of the connecotor or connectorRef MUST be present in the resource object. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Resource private namespace. This is the namespace that is private for a specific resource INSTANCE. It may be used by the connector e.g. to generate instance-specific resource schema or for other purposes. It should be set by the system administrator to a unique value for each resource instance. The configuration tools (e.g. admin GUI) should provide a reasonable default value. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Schema for resource objects. This element contains the XSD-formatted definition of resource schema. It defines data types for accounts, groups, roles, entitlements, organizational units or any other objects related to identity management that the resource supports. Resource schema will be only available at run-time and can be diffrent for every resource instance, even for resource instances of the same type. It is supposed to be dynamically interpreted in run-time. Schema defines data types (XSD types), but it does NOT define how these types are handled. E.g. it defines attributes and object class for inetOrgPerson, it defines that inetOrgPerson extends organizationalPerson and persona, that cn is multi-valued string attributed of Person, etc. But it does NOT define that inetOrgPerson object class should be used as account and that modifyTimestamp attribute is read-only. Such additional details are specified in schemaHandling element defined below. Resource schema is read-only. Changing resource schema is not supported. TODO: annotations in the schema </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> The capabilities nativelly supported by the connector without any simulation or any other workaround. This may not be stored in the repository, as this can be fetched any time from the connector. If this element is not present then the connector provides no capabilities. The value of this element indicates what the connector can do. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> The capabilities supported by the resource, including both native capabilities of the connector and simulated capabilities. If this element is not present at all, the value of nativeCapabilities element is assumed. The value of this element is not generated, it should be set by the administrator. The value of this element indicates administrator decisions what connector capabilities to use, what capabilities to simulate and how to simulate them. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> This element contains the XSD-formatted definition of schema. The schema available in this definition is expeceted to comply to the usual midPoint schema structure (properties, property containers), although it should not contain objects (persistent objects identified by OID). Note: This schema is considered to be available only in run-time. Therefore code-generation methods such as JAXB cannot be applied here. Note: xsd:any is here, but maybe a stricter type would be preferable. However xsd:any seems to be a common practice (e.g. SPML, WSDL). </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="strict"> <xsd:annotation> <xsd:appinfo> <xjc:dom/> </xsd:appinfo> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Specification of handling details for resource schema. E.g. read-only or read-write attributes, account object classes, etc. TODO: more details This element belongs to ResourceType and should not be used elsewhere. This is a top-level element to make the implementation (JAXB marshall/unmarshall) easier. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Defiens a type from the resource schema (object class) that can be used for creating accounts. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:annotation> <xsd:documentation> Human readable name for the account object class. This name may be displayd in tools and GUIs to provide more pleasant user experience, as the XML data type names may look quite frightening. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> XSD type from the resource schema (Object Class) that should be used for accounts on this resource. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element maxOccurs="unbounded" minOccurs="0" name="attribute" type="tns:AttributeDescriptionType"> <xsd:annotation> <xsd:documentation> Specification of handling of an account attribute. This overrides annotations in the resource schema. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Definition of credentials handling for this account type. EXPERIMENTAL. Will most likely change later. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:annotation> <xsd:documentation> If true then the passowrd of the resource account will be automatically changed when user password is changed. EXPERIMENTAL. Will most likely change later. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> If set to any value, the password will be randomly generated when a new account is created and the password cannot be determined otherwise. If set to zero, empty password will be generated. If not set at all, the password attribute will not be present. If a password can be determined otherwise (e.g. from User object), the random generation will not be applied. EXPERIMENTAL. Will most likely change later. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:annotation> <xsd:documentation> Short string identifier (name) of the account type E.g. user, tester, guest, ... It is supposed to be used in references to this section of XML defining account type. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> Specifies whether this account type is the default account type for the resource. Only one account type can be default. Setting this flag for more than one type is an error. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <xsd:annotation> <xsd:documentation> Type of entitlements such as groups, roles entitlements, organizatrions, etc. Not yet fully figured out. Please ignore for now. TODO </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:annotation> <xsd:documentation> Human readable name for the object class. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:complexType> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Collection of scripts to be executed for various provisioning operations. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Specific script definition. Note: More than one script definition may apply to a specific operation. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Specifies how and when a script is executed during provisioning. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Defines a set of operations for which the script should be executed. If more than one operation is specified, the same script should be executed for each of them. If no operation is specified, the script will not be executed (this is meant as poor man's disable feature) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Defines the order in which a script is executed. (before or after an operation). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Defines where the script should be executed (connector or resource). If no type is specified, it defaults to resource. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Specifies the language of the script. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Script aguments. The arguments will passed to the script in any way suitable for the script. The argument name is "local" to the script (script-specific). Script name must be unique in the argument set. The order of arguments is not significant. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Script code represented as string. The interpretation depends on script language. If XML elements are used inside, they should be properly escaped. (e.g. using CDATA). </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Type of an operation (change). It defines operations to change object, it is not limited to object modifications. TODO: How to handle renames? </xsd:documentation> </xsd:annotation> <xsd:enumeration value="get"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="GET"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="add"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="ADD"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="modify"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="MODIFY"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="delete"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="DELETE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> An enumeration that defines when the script will be excuted. </xsd:documentation> </xsd:annotation> <xsd:enumeration value="before"> <xsd:annotation> <xsd:documentation> The script will be executed before the provisioning operation. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="BEFORE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="after"> <xsd:annotation> <xsd:documentation> The script will be executed after the provisioning operation. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="AFTER"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> An enumeration that defines where the script will be excuted. </xsd:documentation> </xsd:annotation> <xsd:enumeration value="connector"> <xsd:annotation> <xsd:documentation> The script will be executed on "connector", it means it will be executed on the same host as the connector is running (which is usually IDM system). </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="CONNECTOR"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="resource"> <xsd:annotation> <xsd:documentation> The script will be executed on "resource", it means it will be executed on the target sytem. Please refer to the connector documentation for more details, e.g. in case of multi-host resources. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="RESOURCE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> Script argument. It is subtype of Value Construction, therefore the value may be static of dynamically constructed using an expression. The "default" and "authoritative" flags are not applicable here. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Argument name. The name is "local" to the script. It must comply with the limitations of used script language. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Resource configuration (hostname, port, ...). Specific for each resource type. TODO This element belongs to ResourceType and should not be used elsewhere. This is a top-level element to make the implementation (JAXB marshall/unmarshall) easier. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:annotation> <xsd:documentation> Description of the attribute handling, such as display name, read/write access and value and synchronization expressions. This is supposed to be used in schemaHandling part and therefore describe the decisions of the system administrator about the way how that attribute is used in midPoint. This is supposed to be used only in schemaHandling. It is not a reusable data structure (composition). </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Human readable name for the account attribute. This name may be displayd in tools and GUIs to provide more pleasant user experience, as the native attribute names may look quite frightening (especially in LDAP). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Access to the attribute as defined by the system administrator or deployer. This can constrain the access defined by resource schema annotations. Specifying broader access that the resource connector can handle is an error. If no access is specified, it defaults to read-write. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Defines how the attribute value is constructed in case of information flow from IDM to the resource, e.g. in case of provisioning. This may be a static value or an expression. In case an expression is used, the expression variables should be as follows: $user - the user to whom the account belongs $account - the account to be changed Motivation: This is "value construction" type, it is using similar format that is used eleswhere in the system (e.g. in roles) and therefore a common expression processor can be used to process all of that. E.g. a single processor may take into a consideration both schema handling and dynamic attributes set by roles. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Defines how the attribute values are used (assigned) in case of information flow from resource to IDM, e.g. in case of synchronization, reconciliation or discovery. In case a source expression is used, the expression variables should be as follows: $user - the user to whom the account belongs $account - the account that has been changed (after the change) Explanation: This is not a "value construction" as it is not constructing a new attribute value. It is rather using attribute value that was set be someone else. A simpler way how to express the assignement is needed here, especially a simple way how to express assignment target. Some rules may use that information and we definitelly need that to generate correct relative change descriptions. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:annotation> <xsd:documentation> Name of the property attribute (XSD element) that this definition describes. It must point to the first-level attribute in the resource schema that belongs to an object class that is being described here. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <xsd:annotation> <xsd:documentation> Defines how a value of a property (or attribute) should be constructed. The value may be static or constructed as an result of evaluating an expression. This strucuture also defines a method how to merge several value construction definitions, how to behave if a property already has a value, etc. This is reusable data structure, used in schemaHandling, roles and it may also be used in may other places. Motivation: We need to construct attribute or property values on many places in midPoint. E.g. we need that in roles to generate dynamic account attribute values, we need that to define "templates" for identifiers and default values for attributes when creating a new account. We also need that to specify values when creating a new user (user templates). Having the same data structure for all of these cases may simplify the code, as it all can be handled by a generic library reused in many places throught the system. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:choice> <xsd:annotation> <xsd:documentation> Static value for the attribute or property. Please note that this is nillable and therefore it may be explicitly set to "nil" value. Doing this means that empty set of values should be constructed. E.g. setting this to "nil" and also setting "authoritative" flag may enforce removal of all attribute values (if used properly). </xsd:documentation> </xsd:annotation> <xsd:complexType mixed="true"> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"> <xsd:annotation> <xsd:documentation> Static attribute values. The values in this element should be assigned to the account as-is. List of values for the attribute provided in an propriate XML elements that specify attribute name. (as is usual for properties) Only one attribute may be specified here, although it may have multiple values. Multi-valued attributes are expressed by repeating the same XML element multiple times. Hence all the XML elements that match this xsd:any must have the same element names (may have different values of course). </xsd:documentation> <xsd:appinfo> <jaxb:dom/> </xsd:appinfo> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:sequence> <xsd:annotation> <xsd:documentation> Definition of additional variables that should be present during evaluation of the expression. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Expression to dynamically generate the value. See ExpressionType for more details. The expression will most likely use variables. The names and content of the variables depends on the specific usage of this type. Please refer to the containing or deriving type documentation for more details. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Defines the XPath of a property on which the expression depends. If there are other expressions to be evaluated that set such value, such expressions will be evaluated before this expression. This may or may not be needed. If the dependencies can be derived from the expression implicitly, the dependency element may be omitted. It may also be omitted if the order of expression execution is not significant. In case the user want to make sure that expressions will be executed in a crertain order, he should include dependency elements. Due to the JAXB "feature" this does not work for now. Please do not use it. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:choice> <xsd:annotation> <xsd:documentation> The value will only be valid if the condition is evaluated to true. If the condition is false, the value definition should not be applied at all (exactly as if there is no definition). If there is no condition, it is assumed to be true. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> List of filters that will be applied to the value after it was constructed. The filters will get applied as the very last step, after the expression had run. The filters will be executed in chain in the order as specified here. The filters are supposed to "mess up" or transcode the value from XML standards to any format suitable for native storage (e.g. on resource). (but see the note in ValueFilterType documentation) </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:annotation> <xsd:documentation> The value construction cannot be combined with other value constructions. If there are other non-exclusive value constructions to be applied to the same propert or attribute, such constructions should be ignored. If there are other exclusive value constructions, the error should be produced and the values should not be changed. TODO: not yet finished </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> This value construction should only be applied if the property or attribute does not have a value. This flag makes the value construction conditional. Please note that now there is no way how to get attribute value and set a new value atomically. Therefore also the "default" flag cannot be executed atomically and a risk of inconsistency is still there. The implementation should minimize that risk by making the "window of risk" as shortas possible and utilize any additional consistency guarantees if possible. </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> The value provided by this construction element is authoritative. It means that this value construction is supposed to both add the value and remove it. TODO: not yet finished </xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:annotation> <xsd:documentation> The value construction is supposed to be executed on the "clear" value for a attribute or property. If there are any existing values on the property or attribute before the execution of all applicable value construction definitions, such values should be cleared. TODO: not yet finished </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <xsd:annotation> <xsd:documentation> Definition of construction of a (general) property. The property may be constructed as a static value of as a result of an expression (See ValueConstructionType documentation). This can be used e.g. to constuct a value for user's fullName in User Template or also on other places in the future. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Reference (QName) of the property which value is defined by this type. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Defines an assignment of value from one place (or expression) to another place. This is supposed to be a general-purpose construct. TODO: merging options This type is marked with jaxb:dom annotation, which will avoid JAXB parsing of it. This is a workaround to a JAXB limitation, which cannot handle more than one "any" elements in a type. See http://java.net/jira/browse/JAXB-798 </xsd:documentation> <xsd:appinfo> <jaxb:dom/> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> List of filters that will be applied to the value before it even gets processed by this assignment. The filters will get applied even before the expression. The filters will be executed in chain in the order as specified here. The filters are supposed to "clean up" or transcode the value to comply with usual XML standards. (but see the note in ValueFilterType documentation) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Source of assignement. R-value. The value (or values) will be copied from this place or from the result of the expression. Depending on how this type is used, the source may be implicit. Therefore the source definition is optional. The expression will most likely contain variables. Please refer to the documentation of containing or derived type for more details. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Destination of the assignment. L-value. The value (or values) will be copied to this place. It is an XPath pointer that must point to an existing, mutable part of XML document. The copy will replace all existing values. But that behavior may change in the future. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Defines value filter. The value filters are supposed to take a single value of a specific type and return a single value of the same type. Filters are used to transforms values, e.g. to clean up illegal characters, to do charset transcoding, etc. Note: Strictly speaking, filters should be used for things like transliteration of national characters, case conversions, etc. They should not be used to "technical" transformations such as character set conversions. Connector should do that and connector should return nice, clean unicode strings. But some connectors are faulty and the ability of filters to do "technical" things may come handy. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax"> <xsd:annotation> <xsd:documentation> Filter parameters. </xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:annotation> <xsd:documentation> URI identifying the type of the filter. This is a identifier of the filter code. Individual filters may plug-in under a specific URI. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <xsd:annotation> <xsd:documentation> Defines a synchronization properties (configuration) for a resource. TODO: add reconciliation setup (later) </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Flag indicating if the synchronization is enabled. If it is not, the synchronization process will be suspended. If enabled, the synchronization should pull in even the changes that were done during disabled synchronization (limitations may apply, such as the legth of history logs on the resource). Disabling synchronization means that it will not be executed automatically (e.g. polling resource in regular intervals). The synchronization may still be executed explicitly (manually), even if it is disabled. If this flag is not present, but a valid synchronization setup is found (which usually means valid "synchrnization" element), the synchronization is assumed to be enabled. This flag is meant to act as a tool to temprarily disable synchronizatoin without loosing the configuration and and state. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Correlation expression. It should return a list of candadate user entries that may be owners of a particular account. Correlation is an rough but an efficient way how to relate the account to a user. The correlation expression is in fact just a search filter. If correlation search returns more that one entries, confirmation expression will be executed for each of them. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Confirmation expression. The arguments are an account and a candidate owner (user). The confirmation expressions should return true if the user should be owner of the account. It should return false if the user cannot be owner of the account. The evaluation of the confirmation expression may be relativelly inefficient, as it will only be run for candidate entries returned by correlation expression. The expression variables should be set as follows: $user - the candidate user object (one of the results of correlation expression) $account - the changed account object </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Reaction to a synchronization situation. Situation identifier must be unique in this set (i.e. a situation definition may occur only once for each situation). If there is no definition for a particular situation, there will be no reaction ("do nothing"). The set of situation reactions is considered to be unordered. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:annotation> <xsd:documentation> Defines a particular synchronization situation. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Defines an action to take when a situation is encountered. If there is no action for a particular situation, there will be no reaction ("do nothing"). There may be sevaral actions defined here. In such case all the actions will be executed in the order as they are defined here. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax"> <xsd:annotation> <xsd:documentation> Action parameters. TODO </xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:annotation> <xsd:documentation> Action identifier (URL) TODO </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:enumeration value="confirmed"> <xsd:annotation> <xsd:documentation> The account exists as it should. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="CONFIRMED"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="collision"> <xsd:annotation> <xsd:documentation> The account is assigned to two or more IDM users. TODO: Do we need this situation? </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="COLLISION"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="deleted"> <xsd:annotation> <xsd:documentation> The account existed on the resource, but it has been deleted. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="DELETED"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="missing"> <xsd:annotation> <xsd:documentation> The account should exist on the resource but it does not. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="MISSING"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="found"> <xsd:annotation> <xsd:documentation> The new account is found on the resource (it exists) and IDM determines exactly one owner for that account in IDM and that owner should have the account (e.g. has a valid assignment that implies such account). </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="FOUND"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="unassigned"> <xsd:annotation> <xsd:documentation> The new account is found on the resource (it exists) and IDM determines exactly one owner for that account in IDM and that owner should not have the account. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="UNASSIGNED"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="unmatched"> <xsd:annotation> <xsd:documentation> The new account is found on the resource (it exists) and IDM cannot determine any owner for the account. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="UNMATCHED"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="disputed"> <xsd:annotation> <xsd:documentation> New account is found and two or more owners are found for it. </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumMember name="DISPUTED"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> Description of a generic connector. Connector in midPoint is any method of connection to the resource. The actual implementation, connector framework or protocol does not matter. More specific types derived from this type may exists. E.g. a connector framework may create a derived type and return that instead of this type. The values of "framework", "connectorType" and "connectorVersion" (if present) together form a unique identification of the connector. That means that two ConnectorType objects that have these values same represent the same connector. Only one such instance of ConnectorType should exist in the repository. Note: The ConnectorType does not describe only Identity Connector Framework (ICF) connectors, it is much more generic. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Identification of the framework or mechanism that implements this connector. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Type of the connector, as seen by the framework. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Version of the connector. Used only for display purposes and for searching during imports. Therefore it may be any (sensible) string, but it should be reasonably stable to avoid broken imports. May be any string (numberic convention is recommended, but not required). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Name of a package that the connector comes in. It may be a name of the JAR file, ICF bundle name, URL or any other designation of the packaging. This is optional, it may not be provided. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Identification of the kind of target system that the connector can connect to, such as "LDAP" or "DB Table". Used only for display purposes and for searching during imports. Therefore it may be any (sensible) string, but it should be reasonably stable to avoid broken imports. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Connector-private namespace. This is the namespace that is private for a specific connector (and optionally connector version). It may be used by the connector to generate connector configuration schema or for other purposes. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Connector host that hosts this connector. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Reference to the connector host that hosts this connector. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Connector configuration schema. This element contains the XSD-formatted definition of connector configuration schema. It defines connector configuration variables and data types such as host names, ports, administrator names and so on. Connector schema will most likely be only available at run-time and will be diffrent for every connector. It is supposed to be dynamically interpreted in run-time. Connector schema is read-only. Changing the schema is not supported. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Host definition for remote connector, remote connector framework or a remote "gateway". Note that this is a generic concept of a connector host, not specific to any connector framework. It can be extended with a framework-specific configuration using the usual "extension" element. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Hostname of a remote host. May also be an IP address. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Port number of the remote service. If not present, default port number is assumed by the implementation. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Shared secret used to authenticate client to the host. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Timeout (in milliseconds) used when initially connecting to the host or during other connections when timeout is not otherwise specified. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Local copy of any object on the provisioning resource that is related to provisioning. It may be account, group, role (on the target system), privilege, security label, organizational unit or anything else that is worth managing in identity management. This XML object provides a representation of the resource object in the IDM system, in the LOCAL REPOSITORY. It may represents a minimal data structure in IDM repository that contains only identifier and nothing else. It may also represent a rich structure with a lot of cached or fetched data. The actual content of this object depends on usage: on the specific interface and operation used and even on the system state and configuration. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <!-- xsd:choice --> <xsd:annotation> <xsd:documentation> Reference to a resource that this resource object shadow belongs to. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Resource that this resource object shadow belongs to. </xsd:documentation> </xsd:annotation> </xsd:element> <!-- /xsd:choice --> <xsd:annotation> <xsd:documentation> TODO This QName instead of URI becase it may refer to a foreign (non-midPoint) schema. Such schemas may have uknown URI-QName mapping, therefore using QName seems to be more reliable. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:choice> <xsd:sequence> <xsd:annotation> <xsd:documentation> Attribute values from the resource. The values may be freshly fetched from the resource or cached. The set of attributes may be empty, may provide a complete copy of the resource object or anything in between. This depends on the implementation of the caching and fetching strategy, configuration of the provisioning service or operation that was invoked. While this object is stored, attibutes set will contain attribute values that are (persistently) cached from the resource. At the normal case there should be at least attributes that identify the resource object on the resouce (identifiers). This will be a single attribute in a normal case, something like uid, username, DN, etc. But if a single attribute is not enough to identify the account, more than one attribute may be present. There also may be no attributes. This can happen e.g. if IDM system knows that user should have account on the resource, but the account is not yet created and no identifier is yet assigned to it. This schema does not distinguish which attributes are idenfiers are which are ordinary attributes. That can be learned from the resource schema provided byresource or resource connector. Motivation: resource schema is dynamic, the attribute that is identifier for a specific object may be different for different resources, even if the resources are of the same type (e.g. directory servers with different LDAP schema). And we do not really need to know which of the attributes is identifier in the compile-time. Knowing that in run-time is enough. Please note that this may be out of sync with regard to the resource. In some operations (e.g. lookup) it will be only milliseconds old, but in case of sotred cached values this may be days or even weeks old value. Even though there is a single extenaible element "attributes", we do not want to put its content directly to the body of resource object. Doing so will cause problems with UPA rule and it will effectively prohibit the the of type replacement extensibility on this object. This element is supposed to be used only for resource object that follow standard resource schema. It must not be used for other resource objects. </xsd:documentation> <xsd:appinfo> <a:propertyContainer/> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:any maxOccurs="1" minOccurs="1" namespace="##other" processContents="lax"> <xsd:annotation> <xsd:documentation> Any representation of resource object (as a single element). This may be used only for resource object that do not use standard resource schema. For non-standard resource schemas. </xsd:documentation> <xsd:appinfo> <xjc:dom/> </xsd:appinfo> </xsd:annotation> </xsd:any> </xsd:choice> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Account object type. Represents account on a target system. May be used for locally caching the account data (in local repository). This is not much more than a marker type, but it is necessary as accounts are important objects in identity management and a lot of functionality has special behavior for accounts. This object is supposed to be stored in LOCAL REPOSITORY, it is NOT the object on provisioning resource. For that please see the resource schema which is dynamic and may be different for each resource. There is a standard Account type in standard resource schema provided by midPoint project. Resource connectors should use that as a supertype (marker type) for accounts, but there may be exceptions. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <!-- TODO Account Type --> <xsd:annotation> <xsd:documentation> The set of account credentials (such as passwords). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO For more details see the ActivationType documentation. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- Following types SHOULD NOT be here. They should be in the respository WSDL definition. However, there is a bug in OpenESB (OPENESB-5) and placing the elements to this namespace works around that bug. This should be moved to the WSDL once the bug is resolved. --> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="0" name="object" type="tns:ResourceObjectShadowType"/> </xsd:sequence> </xsd:complexType> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:element name="resourceObjectShadow" substitutionGroup="c:object" type="tns:ResourceObjectShadowType"/> <!-- Following types SHOULD NOT be here. They should be in the provisioning WSDL definition. However, there is a bug in OpenESB (OPENESB-5) and placing the elements to this namespace works around that bug. This should be moved to the WSDL once the bug is resolved. --> <xsd:annotation> <xsd:appinfo> <a:propertyContainer/> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="1" namespace="##other" processContents="lax"> <xsd:annotation> <xsd:appinfo> <xjc:dom/> </xsd:appinfo> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:appinfo> <a:propertyContainer/> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:any maxOccurs="unbounded" minOccurs="1" namespace="##other" processContents="lax"> <xsd:annotation> <xsd:appinfo> <xjc:dom/> </xsd:appinfo> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> <!-- CONVENIENCE ELEMENTS Following definitions are there to use in examples, import files, etc. These should not be used in the services --> <xsd:complexType> <xsd:annotation> <xsd:documentation> Object list, to be used in import files and examples. </xsd:documentation> <xsd:appinfo> <a:propertyContainer/> </xsd:appinfo> </xsd:annotation> <xsd:sequence> </xsd:sequence> </xsd:complexType> </xsd:element> <!-- MODEL SCHEMA --> <!-- The following clauses belong to the model schema, not here. But due to a couple of OpenESB bug (see OPENIDM-124) we were forced to include the whole model and identity schema in this namespace. It's bad, ugly and very dangerous. But there is no other known solution. If you know one, please let us know. We will really appreciate that. --> <xsd:annotation> <xsd:documentation> IDM Model schema defines the structure of roles, rules, access policies, method of assignment of accounts and other resource objects and all the properties of access control model. It is based on the identity schema, using concepts of User, Account Shadow and so on. IDM Model schema is static, it is available in compile-time. Current IDM model schema defines very minimal RBAC model. It is defined as temporary model to allow midPoint to be usable while we take the time to design a full-featured complex IDM model. Expect that the model will be replaced and do not depend on this schema in low-level components (except perhaps repository). </xsd:documentation> </xsd:annotation> <xsd:annotation> <xsd:documentation> Generic expression. The purpose of the expression is to return a value. The expression must produce something that is a piece of XML, which means that it may produce either string value, XML node or a list of XML nodes. The expression may use variables or arguments. However, such variables or arguments passed to the expression will be different for each invocation. It should be documented in each case this type is used. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> QName of the XML node that the expression is supposed to produce. This attribute is optional. If this attribute is used and the expression produces a string output, the output should be considered as the content of a XML element defined by the contect of this attribute. If the expression produces a XML node or a set of nodes, the node(s) should match the content of this attribute. However, the exact interpretation of this attribute is not defined here, it may be different for each use of this type. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Language of the expression. The expressions in multiple languages may be supported in later versions of midPoint. Now the only supported language is XPath 1.0, which is also the default language. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> The expression code is supposed to be in the contect of this type. The content ix "mixed" which allows both XML and non-XML languages. The expression may use variables or arguments. However, such variables or arguments passed to the expression will be different for each invocation. It should be documented in each case this type is used. </xsd:documentation> <xsd:appinfo> <jaxb:dom/> </xsd:appinfo> </xsd:annotation> </xsd:complexType> <xsd:annotation> <xsd:documentation> Boolean condition. The return of this expression must be either true or false. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Definition of a variable. This type declares a variable name and defines the initial content of the variable. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:choice> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:sequence> <xsd:annotation> <xsd:documentation> Variable name. The variable will be presented to the expression using specified name. The name is a QName, which is good for XML-based expression languages such as XPath. For languages with flat names the namespace is fixed (see documentation of midPoint language binding) and the only relevant name is the local part. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO Experimental object. MOST LIKELY WILL CHANGE. TODO: type??? Defines hierarchical objects - or more exactly nested. may contain other entitlements. Such a containing object, when assigned to user, is equivalent to the union of all contained objects (and objects contained in the contained objects, ad infinutum). There is no constrain that the containing and contained objects must be of the same type. Therefore it should be possible to create a "business role" that will contain a set of "IT roles" that specify access to resources and a set of "IDM roles" that gives user administrator privileges in midPoint system. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:choice maxOccurs="unbounded" minOccurs="0"> <xsd:annotation> <xsd:documentation> Contained object. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Reference to the contained object. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> A role that implies assignments. The role may "grant" accounts on resources, attributes and entitlements for such accounts. The role can also assign organizational units, other roles or various IDM objects that can be assigned directly to user. Role is in fact just a named set of assignments. The speicific roles are also called technical role or IT role, however this definition is an abstract definition of concept that can span wide area of intepretation. This is the basic building blog of role-based access contol (RBAC) in the provisioning system. It defines what rights (e.g. accounts) should be given to user, how they should look like (attributes) and what groups or native roles to assign to them (entitlements). This role definition is quite simplistic now. It does not support rule-derived values or any other advanced dynamics. Yet. It will be extended later in the development. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Set of roles's assignments. Represents objects (such as roles) or accounts assigned to the role and therefore implied by the role. The assignment may contain account construction. Such element specified the account specified by this element should be created when the role is assigned (unless such account already exists). The account should be set up according to the definitions contained in this element. TODO: variables in the expressions: $user $role $assignment $account $resource If the role implying this account is unassigned and no other role or assignment implies the account, the account should be removed. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:sequence> <xsd:choice> <xsd:annotation> <xsd:documentation> Reference to a resource that should host the implied account. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Resource that should host the implied account. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> <xsd:choice> <xsd:annotation> <xsd:documentation> Type of account that should be created on the resource. This must point to the a valid accountType definition in the resource object (in schemaHandling section). This element is optional. If not specified then the account type marked as default in the resource definition should be used. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Expression that determines type of account that should be created on the resource. TODO: more The variables should be set as follows: $user - the user that this account will belong to $assignment - an assignemt that is assigning the object in which context is this expression evaluated (e.g. assignment of role) </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> <xsd:annotation> <xsd:documentation> The account is implied only if the condition is evaluated to true. If condition is not present, it is assumed to be true. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Account attribute values implied by this role. When the role is assigned the attributes specified below should be assigned values specified below. When the role is unassigned, the values specified below should be removed unless some other role is still specifying them. TODO: this is very simplistic now. Later we need flags for value removal, authoritativeness, merging approach, etc. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element maxOccurs="unbounded" minOccurs="0" name="entitlement" type="tns:EntitlementConstructionType"> <xsd:annotation> <xsd:documentation> Assignments implied by this role. When the role is assigned the assignable types (groups, native roles) specified below should be assigned to the account. When the role is unassigned, the assignable types specified below should be unassigned unless some other role is still specifying them. TODO: this is very simplistic now. Later we need flags for value removal, authoritativeness, merging approach, etc. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexContent> <xsd:choice> <xsd:annotation> <xsd:documentation> Type of entitlement that should be created on the resource. This must point to the a valid entitlementType definition in the resource object (in schemaHandling section). This element is optional. If not specified then the entitlement type marked as default in the resource definition should be used. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Expression that determines type of account that should be created on the resource. TODO The variables should be set as follows: $account - the account that this entitlement will be part of $user - the user that such account will belong to $assignment - an assignemt that is assigning the object in which context is this expression evaluated (e.g. assignment of role) </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> The user template used to create new users. It contains fixed values or expressions that can set-up a new user obejct. It is used only during user creation in the synchronization code, but will be most likely used also on other places later. The goal is to make this a kind of "policy" how the use object should look like and check it on every user modification. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="0" name="propertyConstruction" type="tns:PropertyConstructionType"> <xsd:annotation> <xsd:documentation> Defines how any of the User's properties should be constructed. It can contain fixed value or an expression. In case an expression is used following variables should be set: $user - The user object being created. $account - (optional) the account from which was the user created (if present) Note: the expressions will be evaluated in the order as they are specified in the XML file for now, as the dependency mechanism does not work yet. Later, the order should be insignificant. </xsd:documentation> </xsd:annotation> </xsd:element> <!-- TODO: Assignment construction. Later. --> <xsd:element maxOccurs="unbounded" minOccurs="0" name="accountConstruction" type="tns:AccountConstructionType"> <xsd:annotation> <xsd:documentation> Defines an account that the user should have. It defines the resource and account type. Such account will be created (if it does not yet exist) and will be linked to the user. Usual outbound expressions from the resource definition are used to set-up the account parameters. This may be non-systemic short-term solution. We need a way how "assign" the account to the user correctly. </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- OPERATIONAL SCHEMA --> <!-- The following clauses belong to the operation support. --> <!-- TODO - check --> <xsd:complexContent> <xsd:sequence> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:sequence> <xsd:annotation> <xsd:documentation> Number of days before password expires -1 : means password doesn't expire 0 : means password is expired </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Number of days before password expiration to send warnings (0 means no warnings) </xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:minInclusive value="0"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:annotation> <xsd:documentation> Number of days after password after password expiration the account will be locked (0 means never will be locked) </xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:minInclusive value="0"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:annotation> <xsd:documentation> Number of days before password may be changed (0 means password can be changed immediately) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Number of unique passwords in history (0 - no history) </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Definition of complexity and string policy </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element default="false" maxOccurs="1" minOccurs="0" name="checkAgainstDictionary" type="xsd:boolean"/> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Definition of valid single string limitation </xsd:documentation> </xsd:annotation> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Definition of valid characters in class. Default value is ASCII printable characters (Codes 0x20 to 0x7E) </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:choice> <xsd:element maxOccurs="unbounded" minOccurs="1" name="characterClass" type="tns:CharacterClassType"/> </xsd:choice> </xsd:sequence> </xsd:complexType> <!-- End of TODO --> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Error or warning message. This is optional, as some types does not need a message (e.g. success). </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element maxOccurs="unbounded" minOccurs="0" name="partialResults" type="tns:OperationResultType"/> </xsd:sequence> </xsd:complexType> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:sequence> <xsd:any minOccurs="0" processContents="lax"> <xsd:annotation> <xsd:documentation> Value of the entry. If there is a object that can native XML representation, such representation should be used. Otherwise the UnknownJavaObject can be used. </xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumClass/> </xsd:appinfo> </xsd:annotation> <xsd:enumeration value="success"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="SUCCESS"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="warning"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="WARNING"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="partial_error"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="PARTIAL_ERROR"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="fatal_error"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="FATAL_ERROR"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="not_applicable"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="NOT_APPLICABLE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="in_progress"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="IN_PROGRESS"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="unknown"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="UNKNOWN"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> Type used to represent Java objects that are otherwise unknown to the system and cannot be represented in "canonical" XML form. This must be used only in diagnostics messages intended to be displayed to the human user. It must not be used in places indended for computer processing. </xsd:documentation> </xsd:annotation> <xsd:sequence> </xsd:sequence> </xsd:complexType> <!-- Configuration types --> <xsd:annotation> <xsd:documentation> System configuration object. Holds global system configuration setting. There will be just one object of this type in the system. It will have a well-known OID. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:sequence> <xsd:annotation> <xsd:documentation> Persistent configuration of logging levels, categories, etc. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> User template that will be used "universtally" in all situations regarding user internal consistency. TODO: better documentation </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element maxOccurs="1" minOccurs="0" name="defaultUserTemplateRef" type="c:ObjectReferenceType"> <xsd:annotation> <xsd:documentation> Reference to the default user template that will be used "universtally" in all situations regarding user internal consistency. TODO: better documentation </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Global configuration of connectors and connector frameworks. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:annotation> <xsd:documentation> Global configuration properties of a connector framework. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:annotation> <xsd:documentation> This element may contain any framework-specific global configuration. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> The path to the connector artifacts such as JAR files or directories containing the connector code. The specific meaning may vary slightly for each connector framework. The connector framework may also provide a default path in case nothing is specified here (or addition to what is specified here). </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> Configuration of logging levels, categories, log files, etc. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element maxOccurs="unbounded" minOccurs="0" name="subSystemLogger" type="tns:SubSystemLoggerConfigurationType"/> <xsd:element maxOccurs="unbounded" minOccurs="0" name="classLogger" type="tns:ClassLoggerConfigurationType"/> <xsd:element maxOccurs="unbounded" minOccurs="0" name="appender" type="tns:AppenderConfigurationType"/> <xsd:element maxOccurs="1" minOccurs="0" name="advanced" type="tns:AdvancedLoggingConfigurationType"/> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Contains free form loging configuration. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:any maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Configuration of the logger: the facility that collects log messages from the code. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Logger level </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO: packages are OR-ed TODO: string, wildcards allowed (* as in java) </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Appender name defined in appenders section in logging configuration </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> Configuration of the logger: the facility that collects log messages from subsystem code. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:annotation> <xsd:documentation> Logger level </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> TODO: components are OR-ed TODO: string, but there should be a way how to determine list of valid categories. Maybe switch to enum later. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:annotation> <xsd:documentation> Appender name defined in appenders section in logging configuration </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumClass/> </xsd:appinfo> </xsd:annotation> <xsd:enumeration value="ALL"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="ALL"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="OFF"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="OFF"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="ERROR"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="ERROR"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="WARN"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="WARN"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="INFO"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="INFO"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="DEBUG"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="DEBUG"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="TRACE"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="TRACE"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="ALL"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="ALL"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> TODO </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumClass/> </xsd:appinfo> </xsd:annotation> <xsd:enumeration value="ALL"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="ALL"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="MODEL"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="MODEL"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="PROVISIONING"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="PROVISIONING"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="REPOSITORY"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="REPOSITORY"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="WEB"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="GUI"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="TASKMANAGER"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="TASKMANAGER"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="RESOURCEOBJECTCHANGELISTENER"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="RESOURCEOBJECTCHANGELISTENER"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:annotation> <xsd:documentation> Configuration of the logger: the facility that collects log messages from the code. TODO </xsd:documentation> </xsd:annotation> <xsd:sequence> </xsd:sequence> </xsd:complexType> <xsd:complexContent> <xsd:sequence> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:annotation> <xsd:documentation> OID constants for system objects </xsd:documentation> <xsd:appinfo> <jaxb:typesafeEnumClass/> </xsd:appinfo> </xsd:annotation> <xsd:enumeration value="00000000-0000-0000-0000-000000000001"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="SYSTEM_CONFIGURATION"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="00000000-0000-0000-0000-000000000002"> <xsd:annotation> <xsd:appinfo> <jaxb:typesafeEnumMember name="USER_ADMINISTRATOR"/> </xsd:appinfo> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> </xsd:schema> |
This XML schema documentation has been generated with DocFlex/XML RE 1.8.5 using DocFlex/XML XSDDoc 2.5.0 template set. DocFlex/XML RE is a reduced edition of DocFlex/XML, which is a tool for programming and running highly sophisticated documentation and reports generators by the data obtained from
any kind of XML files. The actual doc-generators are implemented in the form of special templates that are designed visually
using a high-quality Template Designer GUI basing on the XML schema (or DTD) files describing the data source XML. DocFlex/XML XSDDoc is a commercial template application of DocFlex/XML that implements a high-quality XML Schema documentation generator with simultaneous support of framed multi-file HTML,
single-file HTML and RTF output formats. (More formats are planned in the future). A commercial license for "DocFlex/XML XSDDoc" will allow you:
Once having only such a license, you will be able to run the fully-featured XML schema documentation generator both with DocFlex/XML (Full Edition) and with DocFlex/XML RE, which is a reduced free edition containing only the template interpretor / output generator. No other licenses will be required! But this is not all. In addition to it, a commercial license for "DocFlex/XML SDK" will allow you to modify the XSDDoc templates themselves as much as you want. You will be able to achieve whatever was impossible to do with the template parameters only.
And, of course, you could develop any template applications by your own! Please note that by purchasing a license for this software, you not only acquire a useful tool,
you will also make an important investment in its future development, the results of which you could enjoy later by yourself.
Every single your purchase matters and makes a difference for us! To purchase a license, please follow this link: http://www.filigris.com/shop/ |