WO2008109244A1 - Dynamic computation of identity-based attributes - Google Patents

Dynamic computation of identity-based attributes Download PDF

Info

Publication number
WO2008109244A1
WO2008109244A1 PCT/US2008/054152 US2008054152W WO2008109244A1 WO 2008109244 A1 WO2008109244 A1 WO 2008109244A1 US 2008054152 W US2008054152 W US 2008054152W WO 2008109244 A1 WO2008109244 A1 WO 2008109244A1
Authority
WO
WIPO (PCT)
Prior art keywords
attribute
identity
computed
data
query
Prior art date
Application number
PCT/US2008/054152
Other languages
French (fr)
Inventor
Cezar Ungureanasu
John H. Zybura
Matthias Leibmann
Pallavi Gajula
Original Assignee
Microsoft Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corporation filed Critical Microsoft Corporation
Publication of WO2008109244A1 publication Critical patent/WO2008109244A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/242Query formulation
    • G06F16/2433Query languages
    • G06F16/244Grouping and aggregation

Definitions

  • Enterprise Identity Management systems control access to information derived from identity-related data stored in various data repositories.
  • Examples of the data include email distribution lists or system resource access rights based on identity-based attributes such as job function, office location, department, and reporting relationship. Maintaining such information often requires an administrator's direct input and a knowledge of the relationships of the data, which can be quite complex.
  • identity attributes such as users, employees, contractors, customers, and the like
  • derived data sets are populated based on current user attributes. The challenge of maintaining this derived data current becomes even more difficult as the both the source and the derived datasets become larger and/or more volatile and/or more distributed.
  • the present disclosure is directed to efficient means of computing derived data for an identity-based management system automatically and dynamically, such as when the source data changes.
  • Computing derived data automatically and dynamically reduces IT costs through automation and timeliness, and increases security by ensuring entitlements are accurately assigned and reported.
  • Dynamically computing the derived data can be applied to identity-based application domains such as attribute-based distribution list memberships regardless where that data is natively accessed.
  • Dynamic computation of identity-based attributes can be implemented as a general rule-based tool for computing data regardless of the types of attributes and attribute relationships used by any specific organization.
  • the rule-base tool can be used to compute derived data from arbitrary attribute-based datasets.
  • the rule set can comprise rules that describe how disparate objects in an identity-based application store are related to one another, and rules which describe the actual computations over the attributes of related objects.
  • the two types or rules allow high-order business logic to be described in a more modular and intuitive way.
  • Productivity is typically improved through reuse of rules describing similar attribute computations which share the same conditions for object relationships.
  • Dynamic computation of identity-based attributes within information system servers allows data to be aggregated and normalized from multiple data sources deployed across the organization, so that not only is all the requisite data for the computation is persisted, but the dynamically computed results can be pushed to the system(s) to be updated with the result as the results are computed. Accordingly, systems (to where the computed results are pushed) do not require knowledge of the computation and necessary relationships of the data. The systems (to where the data is pushed) typically works with its known data types and attributes, while the computation, relationship building, and derivation are typically performed by the information system server. Incorporation of computation of identity -based attributes within an information system server can also be used to leverage the efficient relational query capabilities within an SQL server.
  • FIGURE 1 is an illustration of an example operating environment and system for dynamic computation of identity-based attributes.
  • FIGURE 2 is an illustration of dynamically calculated, identity-based attributes.
  • FIGURE 3 is a top-level illustration of a flow diagram for dynamic computation of identity attributes. Detailed Description
  • one example system for managed code assemblies includes a computing device, such as computing device 100.
  • Computing device 100 may be configured as a client, a server, a mobile device, or any other computing device that interacts with data in a network based collaboration system.
  • computing device 100 typically includes at least one processing unit 102 and system memory 104.
  • system memory 104 may be volatile (such as RAM), non- volatile (such as ROM, flash memory, etc.) or some combination of the two.
  • System memory 104 typically includes an operating system 105, one or more applications 106, and may include program data 107 such that data store monitor 120, attribute computer 122, and cache 124 can be implemented (which are discussed below).
  • Computing device 100 may have additional features or functionality.
  • computing device 100 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape.
  • additional storage is illustrated in FIGURE 1 by removable storage 109 and non-removable storage 110.
  • Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 100. Any such computer storage media may be part of device 100.
  • Computing device 100 may also have input device(s) 112 such as keyboard, mouse, pen, voice input device, touch input device, etc.
  • Output device(s) 114 such as a display, speakers, printer, etc. may also be included.
  • Computing device 100 also contains communication connections 116 that allow the device to communicate with other computing devices 118, such as over a network.
  • Networks include local area networks and wide area networks, as well as other large scale networks including, but not limited to, intranets and extranets.
  • Communication connection 116 is one example of communication media.
  • Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media.
  • modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
  • wireless media such as acoustic, RF, infrared and other wireless media.
  • computer readable media includes both storage media and communication media.
  • computing device 100 system memory 104 (and processor 102, and related peripherals can be used to implement data store monitor 120, attribute computer 122, and cache 124.
  • Data store monitor 120, attribute computer 122, and cache 124 in an embodiment can be used to implement dynamic computation of identity-based attributes (described below with reference to Figures 2-3).
  • Data store monitor 120 can be used for detecting changes to identity-based attributes for structured data in a data store and changes to relationships amongst the structured data.
  • Attribute computer 122 can be used for computing in response to a detected change a computed attribute for a query (that can be an identity function, for example).
  • Cache 124 can be used for persisting the computed attribute and sending the computed attribute in response to a query that be the same (or substantially similar to) or different from the query for which the change was detected.
  • FIGURE 2 is an illustration of dynamically calculated, identity-based attributes.
  • an identity-based attribute computation can be directly associated with an attribute chosen to hold the result of the computation.
  • the chosen attribute thus becomes dedicated to the result of the computation, and can be referred to as a "computed attribute.”
  • the value of a computed attribute typically only changes when the result of the computation itself changes.
  • a straightforward implementation could perform the actual computation on-demand whenever the computed attribute is accessed.
  • another implementation can use a more sophisticated system whereby the result of the computation is cached. While this approach typically requires more physical storage, it typically reduces computational overhead since identity -based attribute computations are normally only executed when the inputs into the computation change.
  • the values of a computed attribute on a specific object are calculated from the attribute values present on a set of related objects (which may or may not include the object holding the computed attribute).
  • a set of related objects which may or may not include the object holding the computed attribute.
  • the object holding the computed attribute is called the "base object” (220)
  • the set of related objects are called “match objects” (210, 230, and 240).
  • the base object itself may also be a match object.
  • the operations can be restricted to only allow the relocation of values to different operations.
  • operations can be supported that modify the content of individual values, such as arithmetic or string manipulation operators.
  • the feature of identity-based attribute computations is typically implemented on top of "normalized" identity data store.
  • any value-level transformations are performed before the data enters the normalized identity store.
  • value-level transformation operators can be provided.
  • the transformation from match object values into computed attribute values is defined by listing the names of one or more attributes from the match objects which thus forms the computed value set. These attributes are called "value attributes.” Thus the result of the computation is the union of all values from all value attributes from all match objects.
  • the definitions are stored in the DSML schema of the aggregate identity store, using custom XML elements to extend the DSML schema description format.
  • the example DSML definition does not describe how the relationships are defined. Not defining the relationships in the DSML code illustrates an important modularity in the definitions of identity-based attribute computations.
  • the conditions that define a relationship are normally established independently of the computations which use those relationships.
  • the modularity allows the logic for a relationship to be reused in multiple computations. It also potentially allows different parties, with different areas of expertise, to author relationships and computations independently.
  • the modularity of the code can thus offer a significant improvement in system manageability.
  • a relationship can be defined as any set of conditions that can be evaluated to determine the set of match objects for a given base object.
  • a relationship can be defined by three optional components: a "filter” on the match object, a “filter” on the base object, and a list of “search conditions.”
  • a “filter” is an arbitrary test that can be applied to a single object to determine if it is a candidate for the relationship.
  • a “search condition” is a test that can take as input both the match object and the base object, and determine if the two objects are related according to the specific attribute values on each.
  • a relationship is determined to exist between two objects when the match filter test passes, when the base filter test passes, and when all search condition tests pass. If any of these tests has not been defined for a given relationship, then that test is considered to always pass.
  • Table II Table II
  • Match filter ⁇ Arbitrary test on match object>
  • Base filter ⁇ Arbitrary test on base object>
  • Search Condition 1 ⁇ Arbitrary condition between both objects>
  • Search Condition 2 ⁇ Arbitrary condition between both objects>
  • a “filter” is defined as a mathematical combination of Boolean operators, conditional operators, constant values, and object attributes.
  • a “search condition” can be primarily defined by two listing attributes, one called the "base attribute” and one called the "match attribute.” A simple search condition is considered to "pass" for a given pair of base object and match object when the match attribute on the match object and the base attribute on the base object share at least one value in common.
  • search condition there can be three additional options on a search condition that influence the matching logic.
  • the first is an "inversion” flag which negates the result of the search condition.
  • an inverted search condition passes for a given pair of objects usually only if the match attribute on the match object has no values in common with the base attribute on the base object.
  • the second and third options are "transitivity" flags which can be independently set on either the match or the base object (discussed below).
  • the definition of a search condition can be given as follows in Table III:
  • Match attribute ⁇ Name of attribute on match object>
  • Base attribute ⁇ Name of attribute on base object> Inverted: ⁇ True/False>
  • a search condition directly tests the immediate values of the match attribute against the immediate values of the base attribute.
  • the transitive flag is turned on for either attribute, then the value set that will be tested for that attribute will actually be the "transitive closure" of the immediate values of the attribute.
  • the transitive closure operation is usually only defined for attributes of reference type, so it is normally invalid to set this flag for a match or base attribute which is not of a reference type.
  • the actual transitive closure operation typically has the standard mathematical definition: the result is the set of all objects reachable through the specified reference attribute in any number of "hops.”
  • the standard "manager" reference-type attribute can be used.
  • relationship definitions can be stored in an aggregated identity store schema using an extended DSML grammar.
  • An example of a relationship definition in using an extended DSML grammar can be as follows:
  • relationship and computed attribute definitions frequently reference other attributes in the identity store schema. According to the given schema, any of these referenced attributes can be themselves computed attributes. Thus a computed attribute can be referenced as a value attribute in another computed attribute. A computed attribute can also be used as a match attribute or base attribute in a search condition. Additionally a computed attribute could be referenced in the match or base filters of a relationship. [0033] These types of nested definitions are allowed to any degree of depth or complexity, such that typically none of the definitions are cyclically related. The dependencies are calculated between the various nested definitions, and calculations are performed in the proper order such that the dependencies are obeyed and all computation results are kept current.
  • FIGURE 3 is a top-level illustration of a flow diagram for dynamic computation of identity attributes.
  • a data store is monitored for changes to identity-based attributes for structured data and changes to relationships amongst the structured data.
  • a computed attribute is dynamically computed for a first query. The calculation is performed in response to the detected change as detected by the data store monitoring above. The query can be persisted in a cache for replying to queries that are the same or similar to (sharing some identical components) the first query. The cache can be implemented in a server.
  • the information from the computed attribute is provided in response to a second query.
  • the second query can be the same as, a duplicate of, similar to, different from (and the like) as the first query.
  • the second query is received after the computed attribute has been computed.
  • the information from the computed attribute can be published (either in conjunction with, or separately from operation 307) by exporting the computed result to a connected system.
  • the connected system can then use the exported results to query against the connected systems querying capabilities.

Abstract

Enterprise Identity Management systems control access to information derived from identity-related data stored in various data repositories. An identity-based management system can automatically and dynamically compute derived data when the source data changes. Rule-base tools can be used to compute derived data from arbitrary attribute-based datasets. Dynamic computation of identity-based attributes within information system servers allows data to be aggregated and normalized from multiple data sources deployed across an organization so that updated related information can be persisted and pushed to various servers in the organization.

Description

DYNAMIC COMPUTATION OF IDENTITY-BASED ATTRIBUTES
Background
[0001] Enterprise Identity Management systems control access to information derived from identity-related data stored in various data repositories. Examples of the data include email distribution lists or system resource access rights based on identity-based attributes such as job function, office location, department, and reporting relationship. Maintaining such information often requires an administrator's direct input and a knowledge of the relationships of the data, which can be quite complex. [0002] As identity attributes (such as users, employees, contractors, customers, and the like) join, leave, and change positions within the organization, their attributes frequently change. This usually requires that relational data be updated as needed to reflect these changed attributes. Conversely, derived data sets (such as new lists or entitlements) are populated based on current user attributes. The challenge of maintaining this derived data current becomes even more difficult as the both the source and the derived datasets become larger and/or more volatile and/or more distributed.
Summary [0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter. [0004] The present disclosure is directed to efficient means of computing derived data for an identity-based management system automatically and dynamically, such as when the source data changes. Computing derived data automatically and dynamically reduces IT costs through automation and timeliness, and increases security by ensuring entitlements are accurately assigned and reported. Dynamically computing the derived data can be applied to identity-based application domains such as attribute-based distribution list memberships regardless where that data is natively accessed. [0005] Dynamic computation of identity-based attributes can be implemented as a general rule-based tool for computing data regardless of the types of attributes and attribute relationships used by any specific organization. The rule-base tool can be used to compute derived data from arbitrary attribute-based datasets. [0006] The rule set can comprise rules that describe how disparate objects in an identity-based application store are related to one another, and rules which describe the actual computations over the attributes of related objects. The two types or rules allow high-order business logic to be described in a more modular and intuitive way. Productivity is typically improved through reuse of rules describing similar attribute computations which share the same conditions for object relationships.
[0007] Dynamic computation of identity-based attributes within information system servers allows data to be aggregated and normalized from multiple data sources deployed across the organization, so that not only is all the requisite data for the computation is persisted, but the dynamically computed results can be pushed to the system(s) to be updated with the result as the results are computed. Accordingly, systems (to where the computed results are pushed) do not require knowledge of the computation and necessary relationships of the data. The systems (to where the data is pushed) typically works with its known data types and attributes, while the computation, relationship building, and derivation are typically performed by the information system server. Incorporation of computation of identity -based attributes within an information system server can also be used to leverage the efficient relational query capabilities within an SQL server. [0008] These and other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive. Among other things, the various embodiments described herein may be embodied as methods, devices, or a combination thereof. Likewise, the various embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The disclosure herein is, therefore, not to be taken in a limiting sense.
Brief Description of the Drawings
[0009] FIGURE 1 is an illustration of an example operating environment and system for dynamic computation of identity-based attributes.
[0010] FIGURE 2 is an illustration of dynamically calculated, identity-based attributes.
[0011] FIGURE 3 is a top-level illustration of a flow diagram for dynamic computation of identity attributes. Detailed Description
[0012] As briefly described above, embodiments are directed to dynamic computation of identity-based attributes. With reference to FIGURE 1, one example system for managed code assemblies includes a computing device, such as computing device 100. Computing device 100 may be configured as a client, a server, a mobile device, or any other computing device that interacts with data in a network based collaboration system. In a very basic configuration, computing device 100 typically includes at least one processing unit 102 and system memory 104. Depending on the exact configuration and type of computing device, system memory 104 may be volatile (such as RAM), non- volatile (such as ROM, flash memory, etc.) or some combination of the two. System memory 104 typically includes an operating system 105, one or more applications 106, and may include program data 107 such that data store monitor 120, attribute computer 122, and cache 124 can be implemented (which are discussed below). [0013] Computing device 100 may have additional features or functionality. For example, computing device 100 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in FIGURE 1 by removable storage 109 and non-removable storage 110. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory 104, removable storage 109 and non-removable storage 110 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 100. Any such computer storage media may be part of device 100. Computing device 100 may also have input device(s) 112 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 114 such as a display, speakers, printer, etc. may also be included.
[0014] Computing device 100 also contains communication connections 116 that allow the device to communicate with other computing devices 118, such as over a network. Networks include local area networks and wide area networks, as well as other large scale networks including, but not limited to, intranets and extranets. Communication connection 116 is one example of communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.
[0015] In accordance with the discussion above, computing device 100 system memory 104 (and processor 102, and related peripherals can be used to implement data store monitor 120, attribute computer 122, and cache 124. Data store monitor 120, attribute computer 122, and cache 124 in an embodiment can be used to implement dynamic computation of identity-based attributes (described below with reference to Figures 2-3). Data store monitor 120 can be used for detecting changes to identity-based attributes for structured data in a data store and changes to relationships amongst the structured data. Attribute computer 122 can be used for computing in response to a detected change a computed attribute for a query (that can be an identity function, for example). Cache 124 can be used for persisting the computed attribute and sending the computed attribute in response to a query that be the same (or substantially similar to) or different from the query for which the change was detected.
[0016] FIGURE 2 is an illustration of dynamically calculated, identity-based attributes. In an embodiment, an identity-based attribute computation can be directly associated with an attribute chosen to hold the result of the computation. The chosen attribute thus becomes dedicated to the result of the computation, and can be referred to as a "computed attribute." The value of a computed attribute typically only changes when the result of the computation itself changes. [0017] A straightforward implementation could perform the actual computation on-demand whenever the computed attribute is accessed. However, to improve processing efficiency, another implementation can use a more sophisticated system whereby the result of the computation is cached. While this approach typically requires more physical storage, it typically reduces computational overhead since identity -based attribute computations are normally only executed when the inputs into the computation change.
[0018] In dynamic computation of identity-based attributes, the values of a computed attribute on a specific object are calculated from the attribute values present on a set of related objects (which may or may not include the object holding the computed attribute). In a server implementation, the object holding the computed attribute is called the "base object" (220), and the set of related objects are called "match objects" (210, 230, and 240). The base object itself may also be a match object.
[0019] After the base and match objects have been established, an arbitrary operation over the set of values from all match objects can be performed to produce a resultant set of values for the computed attribute. In general, any mathematical operation can be used for the computation, depending on the amount of flexibility desired for a given scenario.
[0020] In one embodiment, the operations can be restricted to only allow the relocation of values to different operations. (In other embodiments operations can be supported that modify the content of individual values, such as arithmetic or string manipulation operators.) The feature of identity-based attribute computations is typically implemented on top of "normalized" identity data store. In the embodiment, any value-level transformations are performed before the data enters the normalized identity store. (In other embodiments value-level transformation operators can be provided.)
[0021] In the embodiment, the transformation from match object values into computed attribute values is defined by listing the names of one or more attributes from the match objects which thus forms the computed value set. These attributes are called "value attributes." Thus the result of the computation is the union of all values from all value attributes from all match objects.
[0022] As illustrated in Figure 2, two relationships (250 and 260) and two value attributes are used to compute five values from the three match objects. Thus components used to define a computed attribute for the example comprises two lists. The first is the list of relationships, and the second is the list of value attributes. The definition of CAl in this example can be given as follows in Table I:
Table I
CA1 Definition
Relationships: "Relationship 1",
"Relationship 2"
Value Attributes: "VA1", "VA2"
[0023] In the embodiment, the definitions are stored in the DSML schema of the aggregate identity store, using custom XML elements to extend the DSML schema description format. An example extended DSML definition for CAl can be written as: <ms-dsml : computed-attribute-type id="CAl" ms- dsml : indexed="true" ms-dsml : indexable="true"> <dsml : name>CAl</dsml : name> <ms-dsml rvalue-attribute ref="#VAl" />
<ms-dsml rvalue-attribute ref="#VA2" /> <ms-dsml : relationship ref="#Relationshipl" /> <ms-dsml : relationship ref="#Relationship2" /> </ms-dsml : computed-attribute-type>
[0024] The example DSML definition does not describe how the relationships are defined. Not defining the relationships in the DSML code illustrates an important modularity in the definitions of identity-based attribute computations. The conditions that define a relationship are normally established independently of the computations which use those relationships. The modularity allows the logic for a relationship to be reused in multiple computations. It also potentially allows different parties, with different areas of expertise, to author relationships and computations independently. The modularity of the code can thus offer a significant improvement in system manageability. [0025] A relationship can be defined as any set of conditions that can be evaluated to determine the set of match objects for a given base object. In an embodiment, a relationship can be defined by three optional components: a "filter" on the match object, a "filter" on the base object, and a list of "search conditions." A "filter" is an arbitrary test that can be applied to a single object to determine if it is a candidate for the relationship. A "search condition" is a test that can take as input both the match object and the base object, and determine if the two objects are related according to the specific attribute values on each. A relationship is determined to exist between two objects when the match filter test passes, when the base filter test passes, and when all search condition tests pass. If any of these tests has not been defined for a given relationship, then that test is considered to always pass. The definition of a relationship can be given as follows in Table II: Table II
Relationship Definition
Match filter: <Arbitrary test on match object> Base filter: <Arbitrary test on base object> Search Condition 1 : <Arbitrary condition between both objects> Search Condition 2: <Arbitrary condition between both objects>
Search Condition N: <Arbitrary condition between both objects>
[0026] In an embodiment, a "filter" is defined as a mathematical combination of Boolean operators, conditional operators, constant values, and object attributes. A typical example for a filter might be "title starts-with 'VP' and buildingNumber = 22." This filter would only pass for objects whose "title" attribute has the string prefix "VP" and whose "buildingNumber" attribute has the numeric value 22. [0027] A "search condition" can be primarily defined by two listing attributes, one called the "base attribute" and one called the "match attribute." A simple search condition is considered to "pass" for a given pair of base object and match object when the match attribute on the match object and the base attribute on the base object share at least one value in common.
[0028] However, there can be three additional options on a search condition that influence the matching logic. The first is an "inversion" flag which negates the result of the search condition. In other words, an inverted search condition passes for a given pair of objects usually only if the match attribute on the match object has no values in common with the base attribute on the base object. The second and third options are "transitivity" flags which can be independently set on either the match or the base object (discussed below). The definition of a search condition can be given as follows in Table III:
Table III
Search Condition Definition
Match attribute: <Name of attribute on match object>
Base attribute: <Name of attribute on base object> Inverted: <True/False>
Match attribute transitive: <True/False>
Base attribute transitive: <True/False>
[0029] Normally, a search condition directly tests the immediate values of the match attribute against the immediate values of the base attribute. However, if the transitive flag is turned on for either attribute, then the value set that will be tested for that attribute will actually be the "transitive closure" of the immediate values of the attribute. The transitive closure operation is usually only defined for attributes of reference type, so it is normally invalid to set this flag for a match or base attribute which is not of a reference type. The actual transitive closure operation typically has the standard mathematical definition: the result is the set of all objects reachable through the specified reference attribute in any number of "hops." [0030] For example, the standard "manager" reference-type attribute can be used. For a given user object, the immediate value of the attribute is a reference to the one person who is that user's manager. Additionally, the transitive closure of this attribute is the entire set of the user's manager, the user's manager's manager, and the like, all the way up the management chain of the user in question. [0031] Like the computed attribute definitions discussed above, relationship definitions can be stored in an aggregated identity store schema using an extended DSML grammar. An example of a relationship definition in using an extended DSML grammar can be as follows:
<ms-dsml : relationship-type id="Relationshipl"> <dsml : name>Relationshipl</dsml : name> <ms-dsml :match-filter> <ms-dsml : or-condition>
<ms-dsml : and-condition>
<ms-dsml : relational-predicate operator="not-contains ">
<ms-dsml : left-operand> <ms-dsml :mv-attribute ref="department" />
</ms-dsml : left-operand> <ms-dsml : right-operand> <ms-dsml : constant- value>Internal Affairs</ms-dsml : constant-value>
</ms-dsml : right-operand> </ms-dsml : relational-predicate> </ms-dsml : and-condition> </ms-dsml : or-condition> </ms-dsml : match-filter> <ms-dsml :base-filter>
<ms-dsml : or-condition>
<ms-dsml : and-condition>
<ms-dsml : relational-predicate operator="substring-any"> <ms-dsml : left-operand>
<ms-dsml :mv-attribute ref="description" />
</ms-dsml : left-operand> <ms-dsml : right-operand> <ms-dsml : constant- value>vendor</ms-dsml : constant-value>
</ms-dsml : right-operand> </ms-dsml : relational-predicate> </ms-dsml : and-condition> </ms-dsml : or-condition>
</ms-dsml :base-filter> <ms-dsml : search-condition ms-dsml :positive="false">
<ms-dsml :base-attribute ms- dsml : transitive="false" ref="#company" /> <ms-dsml rmatch-attribute ms- dsml : transitive="false" ref="#department" /> </ms-dsml : search-condition> <ms-dsml : search-condition ms-dsml :positive="true">
<ms-dsml :base-attribute ms- dsml : transitive="true" ref="#manager" />
<ms-dsml rmatch-attribute ms- dsml : transitive="false" ref="#assistant" />
</ms-dsml : search-condition> </ms-dsml : relationship-type>
[0032] As noted above, relationship and computed attribute definitions frequently reference other attributes in the identity store schema. According to the given schema, any of these referenced attributes can be themselves computed attributes. Thus a computed attribute can be referenced as a value attribute in another computed attribute. A computed attribute can also be used as a match attribute or base attribute in a search condition. Additionally a computed attribute could be referenced in the match or base filters of a relationship. [0033] These types of nested definitions are allowed to any degree of depth or complexity, such that typically none of the definitions are cyclically related. The dependencies are calculated between the various nested definitions, and calculations are performed in the proper order such that the dependencies are obeyed and all computation results are kept current.
[0034] FIGURE 3 is a top-level illustration of a flow diagram for dynamic computation of identity attributes. In operation 302, a data store is monitored for changes to identity-based attributes for structured data and changes to relationships amongst the structured data. [0035] In operation 304, a computed attribute is dynamically computed for a first query. The calculation is performed in response to the detected change as detected by the data store monitoring above. The query can be persisted in a cache for replying to queries that are the same or similar to (sharing some identical components) the first query. The cache can be implemented in a server. [0036] In operation 306, the information from the computed attribute is provided in response to a second query. In various embodiments, the second query can be the same as, a duplicate of, similar to, different from (and the like) as the first query. The second query is received after the computed attribute has been computed. [0037] In various embodiments, the information from the computed attribute can be published (either in conjunction with, or separately from operation 307) by exporting the computed result to a connected system. The connected system can then use the exported results to query against the connected systems querying capabilities. [0038] The above specification, examples and data provide a complete description of the manufacture and use of embodiments of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims

WE CLAIM:
I . A computer- implemented method for dynamic computation of identity- based attributes, comprising:
[302] monitoring a data store for changes to identity-based attributes for structured data and changes to relationships amongst the structured data;
[304] in response to a detected change, dynamically computing a computed attribute for a first query; and
[306] in response to a second query, providing information from the computed attribute.
2. The method of claim 1 wherein the first and second queries are the same query.
3. The method of claim 1 wherein the second query is received after the computed attribute has been computed.
4. The method of claim 1 wherein the computed attribute is persisted in a cache.
5. The method of claim 4 wherein the computed attribute is distributed to another system.
6. The method of claim 1 wherein the structured data relationship is defined using a filter on a match object, a filter on an object, and a list of search conditions.
7. The method of claim 6 wherein one of the search conditions is an element of a set comprising an inversion element and a transitivity element.
8. The method of claim 7 wherein the components used to define the computed attribute are defined using a schema.
9. The method of claim 1 wherein the values of a computed attribute on a specific object are calculated from the attribute values present on a set of related objects.
10. The method of claim 1 wherein the operations used to compute a computed attribute allows the relocation of values to different operations.
I 1. The method of claim 10 wherein the operations that modify the content of individual values by using arithmetic and/or string manipulation operators.
12. The method of claim 1 wherein the components used to define the computed attribute comprise a first list of relationships and a second list of value attributes
13. The method of claim 1 wherein the data store is a normalized identity data store.
14. The method of claim 13 wherein value-level transformations are performed before the data enters the normalized identity store.
15. The method of claim 13 wherein value-level transformations are performed after the data enters the normalized identity store.
16. A system for event-based and/or state changes-based parsing of an input file, comprising:
[220] a data store monitor for detecting changes to identity-based attributes for structured data in a data store and changes to relationships amongst the structured data;
[222] an attribute computer for computing in response to a detected change a computed attribute for a first query that is an identity function; and
[224] a cache for persisting the computed attribute and sending the computed attribute in response to a second query.
17. The system of claim 16 wherein a computed attribute is referenced as a value attribute in another computed attribute.
18. A tangible medium comprising computer-executable instructions for: monitoring a data store for changes to identity-based attributes for structured data and changes to relationships amongst the structured data; in response to a detected change, dynamically computing a computed attribute for a first query that is an identity function; and persisting the computed attribute.
19. The tangible medium of claim 18 further comprising providing information from the computed attribute in response to a second query.
20. The tangible medium of claim 18 further comprising using computed attribute as a match attribute or base attribute in a search condition.
PCT/US2008/054152 2007-03-05 2008-02-15 Dynamic computation of identity-based attributes WO2008109244A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/682,093 2007-03-05
US11/682,093 US7962493B2 (en) 2007-03-05 2007-03-05 Dynamic computation of identity-based attributes

Publications (1)

Publication Number Publication Date
WO2008109244A1 true WO2008109244A1 (en) 2008-09-12

Family

ID=39738670

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/054152 WO2008109244A1 (en) 2007-03-05 2008-02-15 Dynamic computation of identity-based attributes

Country Status (2)

Country Link
US (1) US7962493B2 (en)
WO (1) WO2008109244A1 (en)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2460412B (en) * 2008-05-28 2012-09-19 Hewlett Packard Development Co Information sharing
US8171057B2 (en) 2008-10-23 2012-05-01 Microsoft Corporation Modeling party identities in computer storage systems
US20100299738A1 (en) * 2009-05-19 2010-11-25 Microsoft Corporation Claims-based authorization at an identity provider
US9582673B2 (en) 2010-09-27 2017-02-28 Microsoft Technology Licensing, Llc Separation of duties checks from entitlement sets
US20120117015A1 (en) * 2010-11-05 2012-05-10 Nokia Corporation Method and apparatus for providing rule-based recommendations
US8996548B2 (en) * 2011-01-19 2015-03-31 Inmar Analytics, Inc. Identifying consuming entity behavior across domains
CN104737095A (en) 2012-07-24 2015-06-24 美国港口集团公司 Systems and methods involving features of terminal operation including user interface and/or other features
US9495657B1 (en) * 2012-07-24 2016-11-15 Ports America Group, Inc. Systems and methods involving features of terminal operation including TOS-agnostic and/or other features
US9923950B1 (en) * 2012-07-24 2018-03-20 Ports America Group, Inc. Systems and methods involving features of terminal operation including TOS-agnostic and/or other features
US20150235168A1 (en) * 2013-07-24 2015-08-20 Ports America Systems and methods involving features of terminal operation including tos-agnostic, user interface and/or other features
IN2013MU03243A (en) * 2013-10-15 2015-07-17 Tata Consultancy Services Ltd
CN105824855B (en) 2015-01-09 2019-12-13 阿里巴巴集团控股有限公司 Method and device for screening and classifying data objects and electronic equipment
US9942321B2 (en) * 2016-01-06 2018-04-10 Ca, Inc. Identity-to-account correlation and synchronization
CN111695073A (en) * 2020-05-18 2020-09-22 北京字节跳动网络技术有限公司 Information pushing method and device and electronic equipment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088679A (en) * 1997-12-01 2000-07-11 The United States Of America As Represented By The Secretary Of Commerce Workflow management employing role-based access control
US6202066B1 (en) * 1997-11-19 2001-03-13 The United States Of America As Represented By The Secretary Of Commerce Implementation of role/group permission association using object access type
US20020144142A1 (en) * 2001-04-03 2002-10-03 Dalia Shohat Automatic creation of roles for a role-based access control system
US7171411B1 (en) * 2001-02-28 2007-01-30 Oracle International Corporation Method and system for implementing shared schemas for users in a distributed computing system

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7024693B2 (en) * 2001-11-13 2006-04-04 Sun Microsystems, Inc. Filter-based attribute value access control
US7840658B2 (en) * 2002-05-15 2010-11-23 Oracle International Corporation Employing job code attributes in provisioning
US7188094B2 (en) * 2002-07-08 2007-03-06 Sun Microsystems, Inc. Indexing virtual attributes in a directory server system
US7467142B2 (en) * 2002-07-11 2008-12-16 Oracle International Corporation Rule based data management
US7447701B2 (en) * 2002-07-11 2008-11-04 Oracle International Corporation Automatic configuration of attribute sets
US7343628B2 (en) * 2003-05-28 2008-03-11 Sap Ag Authorization data model
US7747559B2 (en) 2003-06-13 2010-06-29 Equifax, Inc. Systems and processes for automated criteria and attribute generation, searching, auditing and reporting of data
US7284000B2 (en) * 2003-12-19 2007-10-16 International Business Machines Corporation Automatic policy generation based on role entitlements and identity attributes
US20050138419A1 (en) * 2003-12-19 2005-06-23 Pratik Gupta Automated role discovery
US20060004848A1 (en) * 2004-05-25 2006-01-05 Williams Evelyn L Methods and system for presenting attributes and associations of managed objects
US7628614B2 (en) * 2004-08-23 2009-12-08 Educational Testing Service Method for estimating examinee attribute parameters in cognitive diagnosis models
US7281045B2 (en) * 2004-08-26 2007-10-09 International Business Machines Corporation Provisioning manager for optimizing selection of available resources
US7483896B2 (en) * 2005-06-06 2009-01-27 Oracle International Corporation Architecture for computer-implemented authentication and authorization
US8214394B2 (en) * 2006-03-01 2012-07-03 Oracle International Corporation Propagating user identities in a secure federated search system
US7860882B2 (en) * 2006-07-08 2010-12-28 International Business Machines Corporation Method and system for distributed retrieval of data objects using tagged artifacts within federated protocol operations

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6202066B1 (en) * 1997-11-19 2001-03-13 The United States Of America As Represented By The Secretary Of Commerce Implementation of role/group permission association using object access type
US6088679A (en) * 1997-12-01 2000-07-11 The United States Of America As Represented By The Secretary Of Commerce Workflow management employing role-based access control
US7171411B1 (en) * 2001-02-28 2007-01-30 Oracle International Corporation Method and system for implementing shared schemas for users in a distributed computing system
US20020144142A1 (en) * 2001-04-03 2002-10-03 Dalia Shohat Automatic creation of roles for a role-based access control system

Also Published As

Publication number Publication date
US20080222096A1 (en) 2008-09-11
US7962493B2 (en) 2011-06-14

Similar Documents

Publication Publication Date Title
US7962493B2 (en) Dynamic computation of identity-based attributes
US11361097B2 (en) Dynamically generating sharing boundaries
US11514076B2 (en) Cooperative naming for configuration items in a distributed configuration management database environment
US11782892B2 (en) Method and system for migrating content between enterprise content management systems
US11082226B2 (en) Zero-knowledge identity verification in a distributed computing system
US9418237B2 (en) System and method for data masking
KR101475964B1 (en) In-memory caching of shared customizable multi-tenant data
US8255370B1 (en) Method and apparatus for detecting policy violations in a data repository having an arbitrary data schema
US8108367B2 (en) Constraints with hidden rows in a database
US20200287719A1 (en) Zero-knowledge identity verification in a distributed computing system
US9442915B2 (en) Semantic application logging and analytics
US10546021B2 (en) Adjacency structures for executing graph algorithms in a relational database
US20070073691A1 (en) Server side filtering and sorting with field level security
US9646071B2 (en) Supporting set-level slice and dice in data warehouses
US6847957B1 (en) Dynamically extensible rule-based expert-system shell for database-computing environments
US11720543B2 (en) Enforcing path consistency in graph database path query evaluation
US20230169056A1 (en) Systems and methods for determining dataset intersection
US11550792B2 (en) Systems and methods for joining datasets
US7970867B2 (en) Hypermedia management system
Vargas et al. Integrating databases with publish/subscribe
US11546381B1 (en) Unified data security labeling framework
CN113220762A (en) Method, device, processor and storage medium for realizing general record processing of key service field change in big data application
US20160328457A1 (en) Information System with Temporal Data
US20200201829A1 (en) Systems and methods for compiling a database
US20130055204A1 (en) Locating isolation points in an application under multi-tenant environment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08743484

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08743484

Country of ref document: EP

Kind code of ref document: A1