Onboarding resources to an identity management system

Identity management is often regarded as the management of information (as held in a directory) that represents items identified in real life (e.g. users, organizations, devices, services, etc). The management of identities is often associated with the management of user credentials and the processes and means by which users might log on to an online system and connect to selected system resources. Identity management systems or subsystems are used in information systems to support the management of identities. For example, a general purpose identity management system may be used to manage user identities and their respective security entitlements in an identity profile to selectively control access to a heterogeneous set of resources such as applications. One aspect of using an identity management system includes “onboarding” a new resource, such as adding a new application for users to access. In this instance, the identity management system configures the identities and user entitlements of the resource. However, there is very little standardization of identity profiles required by the resources. Each resource often requires a different identity profile, and the native identity and access attributes used by the resource may need to be mapped to identity and access attributes in the identity management system. Typically, this is a specialized, manual process and is often time consuming.

The accompanying drawings are included to provide a further understanding of embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and together with the description serve to explain principles of embodiments. Other embodiments and many of the intended advantages of embodiments will be readily appreciated as they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding similar parts.

FIG. 1 is a schematic diagram illustrating an environment of an embodiment in the disclosure.

FIG. 2 is a schematic diagram illustrating an example enterprise computing system including an embodiment of an identity management system of the disclosure.

FIG. 3 is a flow diagram illustrating an example process for onboarding a resource into an enterprise computing system such as the example of FIG. 2 .

FIG. 4 is a flow diagram illustrating a step of the example process for onboarding a resource into an enterprise computing system such as the example of FIG. 2 .

FIG. 5 is a flow diagram illustrating a step of the example process for provisioning in onboarding a resource into an enterprise computing system such as the example of FIG. 2 .

In the following Detailed Description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims. It is to be understood that the features of the various exemplary embodiments described herein may be combined with each other, unless specifically noted otherwise.

FIG. 1 illustrates an example environment of an embodiment of the disclosure. An identity management system 10 is used to couple a plurality of users 12 , to a plurality of resources 14 . The identity management system 10 is configured to manage user identities of the users 12 and security entitlements of the connected resources 14 . In one example, a first user 12 a can have entitlements to full access of sensitive documents stored in a resource 14 a; whereas a second user 12 b can have no access to the documents in resource 14 a. Other combinations are possible, such as third user 12 c can have partial access to resource 14 b; whereas the first user 12 a can have unfettered access to resource 14 b. It will be understood that in typical implementations the identity may accommodate thousands of resources or applications.

The identity management system 10 includes a set of identity attributes pertaining to the users 12 that correspond with native identity attributes of the resources 14 . The syntax of the existing identity attributes is often different than the required syntax of the native identity attributes of the resource. In order to onboard a new resource, the set of identity attributes pertaining to the users is configured to function with the native identity attributes of the resource. An attribute utility 16 is configured to operate with the identity management system 10 to create or modify the correlation of identity attributes pertaining to the users with the native identity attributes. In one example, the attribute utility 16 can be a software program and deployed in a computer-readable medium having a plurality of computer-executable instructions on the medium for performing the task of correlating the identity attributes. In a more specific example, the attribute utility 16 is a web-based application.

The attribute utility 16 helps create or modify the extensible markup language (XML) and extensible stylesheet language (XSL) mapping files of connectors used with the identity management system 10 . In one example, the utility supports bi-directional lightweight directory access protocol (LDAP) and database connectors. The utility provides for loading resource schema directly from the resource and mapping the native identity attributes with the attributes of the identity management system 10 . The map can be stored in an XML file accessible to the connectors, and the system can allow for creating new or editing existing mapping files. The utility can also generate an XSL file for reverse synchronization. Still further, the utility can allow for direct provisioning of entitlements in to the resource.

FIG. 2 illustrates an example enterprise computing system 20 including the identity management system 10 . The identity management system can be configured to run on a computer system 22 having a processor and a memory, such as a server or a group of servers, and the like. The enterprise computing system 20 also includes resources 24 distributed over a network 26 , which can be referred to as the managed environment. In one example, the resources 24 in the managed environment can include an operating system 28 such as a UNIX or UNIX type operating system, an archive directory 30 , and/or a database 32 such as a relational database management system. An example of onboarding a resource can include the process of adding a directory service 34 such as an LDAP server into the managed environment 24 through the use of the attribute utility 16 .

In this example, the attribute utility 16 includes an onboarding tool (not shown), and FIG. 3 illustrates an example process 300 for onboarding a resource, such as the directory service 34 into the enterprise system 20 of FIG. 2 . The process can include aspects provided by an application owner and an identity management system administrator. In one example, the application owner may be familiar with the users and entitlements of the application, such as the example resource 34 , and the identity management system administrator may be familiar with the identity management system and its deployment model in the enterprise computing system 20 . In an embodiment, separate features of the process can be performed with the aid of either the application owner or the identity management system administrator to create efficiencies in onboarding the resources. In some cases, the identity management system administrator and the application owner may be indistinguishable or the same entity. Further, the process 300 is described with reference to an onboarding tool being part of attribute utility 16 . It will be understood that many other configurations are contemplated such as the onboarding tool itself being a stand-alone utility. The onboarding tool can be a single article or a collection of articles such as software programs on a media or memory, or the like.

The process shown in FIG. 3 includes discovering the schema of the resource at 302 . In the discovery step 302 , the onboarding tool connects directly to the resource 34 , retrieves the schema used in the resource, and converts the schema to a resource specific ontology. Such schemata can be expressed as resource description framework schemata (RDFS), web ontology language (OWL), or other kinds of ontologies. In one example, the application owner can use the onboarding tool to discover the resource schema.

Relevant schema fields are selected and tagged with value significance at 304 . The onboarding tool of the utility 16 can, for instance, present the discovered schema from 302 to a user and enable the user to choose the relevant native schema fields of the resource 34 to be managed with the identity management system 10 . The onboarding tool can also be used to enable a user to validate the results of an automapping to an identity concepts catalogue and value significance. As above, the application owner, for instance, can use the onboarding tool to select the relevant schema and tag the value significance in this way.

A connector mapping is generated at 306 . The onboarding tool can be used to generate, or can automatically generate, a connector mapping file, to enable a user to view and validate the connector mapping file, and save the connector mapping file. For example, the connector mapping file can be saved in the memory of the identity management system 10 for ready access. The application owner, for instance, can use the onboarding tool to generate the connector map in this way.

A deployment mapping is generated at 308 . The onboarding tool can generate, or can automatically generate, a deployment mapping file for the new resource 34 . The onboarding tool can be used to enable a user to view, validate, and refine as desired the deployment mapping. The onboarding tool can be used to enable a user to configure deployment-specific items such as synch-in and synch-out, as known, and can save the deployment mapping file. For example, the deployment mapping file can be saved in the memory of the identity management system 10 for ready access. The identity management system administrator, for instance, can use the onboarding tool to generate the deployment map in this way.

The deployment is enabled at 310 . The onboarding tool can be used to enable the user to add the resource 34 to the relevant identity management service of the identity management system 10 . The resource establishes a connection with the identity management system 10 , and can be used to begin provisioning and reconciliation. In addition, the onboarding tool can be used to add or modify entries into an identity concepts catalogue as selected by the application owner and the identity management system administrator. The process of onboarding a resource in FIG. 3 thus includes marking or tagging resource fields with semantic significance of the conveyed values, i.e. value significance tagging. The semantic markers or tags may be taken from a catalogue or ontology that is organized to expose broader and narrower significance and syntactic composition relations between catalogue concepts.

The catalogue can be composed of multiple sub-catalogues, which can include contributions from different entities, such as sub-catalogues of corporate, industry, or other community concepts.

In the present embodiments, each catalogue is expressed in a thesauri-like relation between definitions of concepts and concept relations, or relation expression as in an ontology. In one example of this, the catalogues are expressed in a resource description framework (RDF) vocabulary that makes use of the simple knowledge organization scheme (SKOS). The Simple Knowledge Organization System (SKOS) is a standard common data model for sharing and linking knowledge organization systems via the Semantic Web that has been developed by the World Wide Web Consortium (W3C). Additional properties can be defined for expressing syntactic compositions of concept values from the syntactic expression of sub-ordinate concept values. For example, using a narrowPartitive relation in SKOS. RDF ontologies use Uniform Resource Identifiers (URIs) to name concepts, relation and individuals. The global scope of URIs provides for consistent semantics across resources, such as a common set of identity concepts across applications. Using RDF ontologies for relation expressions is a convenient way to express relationships between concepts, and can facilitate automatic inferencing such as inferring the closure of a SKOS narrowerThan or broaderThan relations.

Semantic tagging of native, provisioning, and profile objects, in other words marking the objects according to their meaning, is implemented in this example by annotations on relations, such as the RDF expressions of the corresponding object schema. The annotations can be saved or organized separately from the schema. In situations where the native schema of different resources (such as a collection of corporate LDAP servers, UNIX servers, or WINDOWS clients) make consistent reuse of native object fields, separately stored semantic annotations can be reused to annotate a new resource. In this way, the annotations provide reusable knowledge within a managed community of the meaning attributed by the community to the value or values conveyed in particular object fields. The central profile schema and their annotations also can provide a growing body of knowledge of the local configuration that can contribute to the generation of mappings between resource and identity of management profile object fields.

FIG. 4 illustrates examples of steps 302 and 304 of FIG. 3 in more detail, i.e. an example preparation process for mapping 400 . The native object schema of the resource are generated or introspected at 402 . The native objects and object fields are selected for provisioning at 404 . The projected native objects and object fields are annotated by tagging at 406 . The annotations in derived provision objects are refined at 408 . In this example, generic annotations can be refined to be more specific such as taking “telephone number” to “office telephone,” “landline telephone,” or the like. In one example, this process is automatic and can be implemented in the onboarding tool as a computer application or web-based application.

FIG. 5 illustrates an example process for field mapping 500 , i.e. step 306 of FIG. 3 . Provisioning object fields and profile object fields with matching annotations are mapped directly to one another at 502 .

Of the remaining unmapped provisioning object fields, a search is made of the catalogue and profile object for profile fields annotated with a narrower semantic tag than the field for which a mapping is sought at 504 . In one possible search algorithm, the search progresses through the catalogue in a breadth first manner starting with the concept of the tagged provisioning object field and stopping at the first level where the profile field is tagged with a concept that is narrowerThan or broaderThan the provisioning object field. In the case of multiple matches, the issue can be presented to the user (owner, administrator, or the like) via a suitable user interface of the tool to resolve the discrepancy.

Of the remaining unmapped provisioning object fields, the catalogue is searched for compositions that can be satisfied from the profile object at 506 . An example provides for a breadth first search of the catalogue—where again the use of other algorithms is contemplated—starting from the annotation applied to the provisioning object field being mapped and stopping at the level of the first match. Again, a case of multiple matches can be presented to the user (owner, administrator, or the like) to resolve.

The remaining unmapped provisioning object fields will either remain unmapped such that their annotations be further refined at 508 , and 502 , 504 , 506 can be repeated. This can also entail the catalog being augmented by the user with new concept entries to enable such refinement.

Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.