Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

The present invention may comprise a system and method for a Virtual
Attribute Federation System (VAFS) and may be composed of a Virtual
Attribute Federation Manager (VAFM) and a system of Virtual Attribute
Enabled Directories (VAED) modified to accept federation of virtual
attributes. The VAFM produces signed and trusted calculation methods and
coordinates a synchronized dispersal of these methods to the VAEDs. The
VAEDs may have local mappings which allow for federation-time
configuration of the calculation methods.

Claims:

1. A system for virtual attribute federation that produces a consistent
result at multiple directories, works in different domains across an
enterprise, supports the retrieval of information from alternate sources
in differing IT environments, supports different directory structures,
protects the directory from compromised calculation methods, and reduces
processor and network load, the system comprising a virtual attribute
federation manager (VAFM), a processing unit, a memory with cache, random
access memory, and virtual attribute enabled directories (VAEDs).

2. The system as defined in claim 1 further comprising a Federated
Attribute Interface (FAI) connected to one or more directories.

3. The system as defined in claim 2 further comprising user directories
connected to data sources.

4. The system as defined in claim 3 further comprising the directories
connecting to object classes.

5. The system as defined in claim 4 further comprising an object
attribute connected to an object class that is mapped to attribute object
mapping.

6. The system as defined in claim 5 wherein the VAED further comprises an
attribute store element, an attribute mapping element, a calculation
element, and a resource map element.

7. A method for virtual attribute federation that produces a consistent
result at multiple directories, works in different domains across the
enterprise, supports the retrieval of information from alternate sources
in differing IT environments, supports different directory structures,
protects the directory from compromised calculation methods, and reduces
processor and network load, the method comprising: managing, by a virtual
attribute federation manager (VAFM) for directory users and virtual
attribute enabled directories (VAEDs) VAED instances; managing, by the
VAFM, of directories; managing, by the VAFM, of data sources; using, by
the VAFM, a Federated Attribute Interface (FAI) to communicate the
changes of the virtual attributes to the VAED instances.

8. The method as defined in claim 7 further comprising passing attributes
to the directories, mapping the attributes, and calculating a value based
upon the mapped attributes.

9. The method as defined in claim 8 further comprising creating instance
calculation parameters and passing the instance calculation parameters to
one or more object instances.

10. The method as defined in claim 9 further comprising passing object
classes to the directory.

11. A computer-readable medium storing computer instructions, which, when
executed, enables a system operating for virtual attribute federation
that produces a consistent result at multiple directories, works in
different domains across the enterprise, supports the retrieval of
information from alternate sources in differing IT environments, supports
different directory structures, protects the directory from compromised
calculation methods, and reduces processor and network load, to perform
steps comprising: managing, by a virtual attribute federation manager
(VAFM) for directory users and virtual attribute enabled directories
(VAEDs) VAED instances; managing, by the VAFM, of directories; managing,
by the VAFM, of data sources; using, by the VAFM, a Federated Attribute
Interface (FAI) to communicate the changes of the virtual attributes to
the VAED instances.

12. The computer-readable medium as defined in claim 11 wherein the steps
further comprise passing attributes to the directories, mapping the
attributes, and calculating a value based upon the mapped attributes.

13. The computer-readable medium as defined in claim 12 wherein the steps
further comprise creating instance calculation parameters and passing the
instance calculation parameters to one or more object instances.

14. The computer-readable medium as defined in claim 13 wherein the steps
further comprise passing object classes to the directory.

15. A method for deploying a system for virtual attribute federation that
produces a consistent result at multiple directories, works in different
domains across the enterprise, supports the retrieval of information from
alternate sources in differing IT environments, supports different
directory structures, protects the directory from compromised calculation
methods, and reduces processor and network load, the method comprising:
managing, by a virtual attribute federation manager (VAFM) for directory
users and virtual attribute enabled directories (VAEDs) VAED instances;
managing, by the VAFM, of directories; managing, by the VAFM, of data
sources; using, by the VAFM, a Federated Attribute Interface (FAI) to
communicate the changes of the virtual attributes to the VAED instances.

16. The method as defined in claim 15 further comprising passing
attributes to the directories, mapping the attributes, and calculating a
value based upon the mapped attributes.

17. The method as defined in claim 16 further comprising creating
instance calculation parameters and passing the instance calculation
parameters to one or more object instances.

18. The method as defined in claim 13 further comprising passing object
classes to the directory.

Description:

FIELD OF THE INVENTION

[0001] One aspect of the present invention provides for a method and a
system for virtual attribute federation that produces a consistent result
at multiple directories, works in different domains across the
enterprise, supports the retrieval of information from alternate sources
in differing IT environments, supports different directory structures;
protect the directory from compromised calculation methods, and reduces
processor and network load.

[0002] There is a need to provide for a new virtual attribute federation
method and system.

BACKGROUND OF THE INVENTION

[0003] Large enterprises, using directories with virtual attributes
(attributes whose values do not reside in the directory), need a way to
federate virtual attributes across directories in different domains in a
manner in which they can provide consistent results in any environment.
Federation of virtual attributes poses unique challenges due to the
dynamic nature of the virtual attribute. Unlike normal attributes, the
virtual attribute does not have a physical value that can be propagated.
Also, the virtual value may change rapidly. Propagating the virtual value
through traditional directory integration causes problems because by the
time the values are propagated they may already be stale or out of date.

[0004] Just In Time (JIT) directory integration provides an option, but
every level of indirection adds latency, processor load, and bandwidth
load. Database federation would not work because the operating
environments (e.g., directory structure, external ports) differ for
different directories and would cause problems for the calculation
method.

[0005] What is needed is a system and method for virtual attribute
federation that produces a consistent result at multiple directories,
works in different domains across the enterprise, supports the retrieval
of information from alternate sources in differing IT environments,
supports different directory structures; protect the directory from
compromised calculation methods, and reduces processor and network load.

[0006] Therefore, there exists a need for a solution that solves at least
one of the deficiencies of the related art.

SUMMARY OF THE INVENTION

[0007] The present invention may comprise a system and method for a
Virtual Attribute Federation System (VAFS) and may be composed of a
Virtual Attribute Federation Manager (VAFM) and a system of Virtual
Attribute Enabled Directories (VAED) modified to accept federation of
virtual attributes. The VAFM produces signed and trusted calculation
methods and coordinates a synchronized dispersal of these methods to the
VAEDs. The VAEDs may have local mappings which allow for federation-time
configuration of the calculation methods.

[0008] Unlike the alternatives, the present invention provides the ability
to federate virtual attributes into VAEDs that are in multiple domains,
connect to different data sources (with different credentials) in each
environment, and have object identities that vary from VAED to VAED. It
can protect the VAEDs from compromised calculation methods. It increases
performance by not incurring run-time delays and reduces overall
processor and network load.

[0009] The present invention may have a system for virtual attribute
federation that produces a consistent result at multiple directories,
works in different domains across an enterprise, supports the retrieval
of information from alternate sources in differing IT environments,
supports different directory structures, protects the directory from
compromised calculation methods, and reduces processor and network load,
the system comprising a virtual attribute federation manager (VAFM), a
processing unit, a memory with cache, random access memory, and virtual
attribute enabled directories (VAEDs).

[0010] The present invention may further comprise a method for virtual
attribute federation that produces a consistent result at multiple
directories, works in different domains across the enterprise, supports
the retrieval of information from alternate sources in differing IT
environments, supports different directory structures, protects the
directory from compromised calculation methods, and reduces processor and
network load, the method comprising:

[0014] using, by the VAFM, a Federated Attribute Interface (FAI) to
communicate the changes of the virtual attributes to the VAED instances.

[0015] The present invention may further comprise a computer-readable
medium storing computer instructions, which, when executed, enables a
system operating for virtual attribute federation that produces a
consistent result at multiple directories, works in different domains
across the enterprise, supports the retrieval of information from
alternate sources in differing IT environments, supports different
directory structures, protects the directory from compromised calculation
methods, and reduces processor and network load, to perform steps
comprising:

[0019] using, by the VAFM, a Federated Attribute Interface (FAI) to
communicate the changes of the virtual attributes to the VAED instances.

[0020] The present invention may further comprise a method for deploying a
system for virtual attribute federation that produces a consistent result
at multiple directories, works in different domains across the
enterprise, supports the retrieval of information from alternate sources
in differing IT environments, supports different directory structures,
protects the directory from compromised calculation methods, and reduces
processor and network load, the method comprising:

[0024] using, by the VAFM, a Federated Attribute Interface (FAI) to
communicate the changes of the virtual attributes to the VAED instances.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] These and other features of this invention will be more readily
understood from the following detailed description of the various aspects
of the invention taken in conjunction with the accompanying drawings in
which:

[0026] FIG. 1A illustrates the use of a Virtual Attribute Federation
Manager (VAFM) of the present invention.

[0027] FIG. 1B illustrates the use of a Virtual Attribute Enabled
Directory (VAED) of the present invention.

[0028] FIG. 2 illustrates both the VAFM and VAEDs having attribute stores.

[0029] FIG. 3 illustrates the VAED attribute store of the present
invention that contains the structures needed for a functional directory.

[0030] FIG. 4 shows the VAED attribute store of the present invention that
contains an AttributeStore and a ResourceMap internally.

[0031] FIG. 5 illustrates a structure of the VAED.

[0032] FIG. 6 illustrates a sequence of the federation steps between the
VAFM and the VAED.

[0033] FIG. 7 illustrates a sequence of the federation steps to create a
federateInstance.

[0034] The drawings are merely schematic representations, not intended to
portray specific parameters of the invention. The drawings are intended
to depict only typical embodiments of the invention, and therefore should
not be considered as limiting the scope of the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

[0035] FIG. 1A shows Structure 100 having Data Processing System 102,
suitable for storing and/or executing program code of the present
invention may include Virtual Attribute Federation Manager (VAFM) System
104 and at least one processor (Processing Unit 106) coupled directly or
indirectly to Memory 110 through System Bus 112. Memory 110 may include
Virtual Attribute Federation Manager 141 having Attribute Store 131,
local memory (RAM 130) employed during actual execution of the program
code and cache memories (Cache 132) that provide temporary storage of at
least some program code in order to reduce the number of times code must
be retrieved from bulk storage (Storage System 118), during execution.
Input/output or I/O devices (External Devices 116) (including but not
limited to keyboards, displays (Display 120), pointing devices, etc.) can
be coupled to Virtual Attribute Federation Manager (VAFM) System 104,
either directly or indirectly through a network (see FIG. 2) through
intervening I/O controllers (I/O interface(s) 114).

[0036] FIG. 1B shows Structure 101 wherein a Virtual Attribute Enabled
Directory (VAED) 140 works within System 103 and within Virtual Attribute
Enabled Directory (VAED) System 105. Memory 111 in this case has Virtual
Attribute Enabled Directory (VAED) 140 that has Attribute Store 142 and
Resource Map 144, local memory (RAM 133) employed during actual execution
of the program code and cache memories (Cache 135) that provide temporary
storage of at least some program code in order to reduce the number of
times code must be retrieved from bulk storage (Storage System 119),
during execution. Input/output or I/O devices (External Devices 117)
(including but not limited to keyboards, displays (Display 121), pointing
devices, etc.) can be coupled to Virtual Attribute Enabled Directory
(VAED) System 105, either directly or indirectly through a network (see
FIG. 2) through intervening I/O controllers (I/O interface(s) 115).

[0037] FIG. 2 is an example and an arbitrary number of directory users may
connect to a VAED 208, 210. VAFM 204 may federate with an arbitrary
number of VAEDs. A DataSource 212, 214 may be used by an arbitrary number
of VAEDs 208, 210. VAED 208, 210 may use an arbitrary number of
DataSources 212, 214. VAFM 104 uses a Federated Attribute Interface (FAI)
205 to communicate the changes of the virtual attributes to the VAED
instances. For the sake of illustration, the VAED instances 208, 210 in
FIG. 2 communicate with different instances of the same DataSource 212,
214. VAEDs 208, 210 also communicate with directory clients 202, 206.

[0038] As shown in FIG. 2, attribute stores 212, 214 are contained
internally within the VAEDs. The Data Sources 212 and 214 are something
outside of the system like a thermometer or Geiger counter, for example.
The attribute store of the VAFM 204 provides a central location for the
directory object 302 (FIG. 3) and its virtual attributes.

[0040] VAFM 204 Attribute Store lacks the Attribute Value 414 for
non-virtual attributes because these values can be propagated through
traditional directory integration techniques. Many relationships are also
missing in VAFM 204. Attribute Store 404 are stored as they are only
needed in a functioning directory. VAFM 204 Attribute Store has a server
Address that the VAFM 204 uses to connect to VAEDs 208 and 210 that need
updating. It may also contain encrypted user ID and password for
connecting to the VAEDs 208 and 210.

[0041] The VAED attribute store 400 contains the structures needed for a
functional directory 208, 210. Directories 208, 210 attribute store 400
lack the server Address attribute since the attribute store resides on a
VAED server. The VAFM Object Instance 312 is mapped to the Object
Instance 412 of the VAEDs 208 and 210 via the Directory 302. Within the
VAFM Attribute Store 300, the Attribute Object Mapping 310 identifies
which Value Calculation Method 308 to use for a specific Attribute 304 of
an ObjectClass 314.

[0043] VAED 500 possesses several measures to protect itself against
compromised Value Calculation Method 408. The VAFM 204 digitally signs
the Value Calculation Method 408 and Attribute 304. If the VAED 500 does
not see the proper signature, it does not execute the Value Calculation
Method 408/508. Within the VAED 500, the Value Calculation Method 408/508
executes in a restricted or "sandbox" environment with the ability to
retrieve information from the Attribute Store 504 or through External
Port(s) 518. This restricted environment prevents Value Calculation
Method 408 from transmitting information outside of VAED 500 (potentially
leaking information), reading information outside of VAED 500 (except
through the designated ports), or changing anything in the Attribute
Store 504. It also prevents the Value Calculation Method 408/508 from
accessing any information that the executing user identity would not have
access to from outside the VAED 500. These provisions protect the VAED
500 from compromised Value Calculation Method 408 that might have been
federated from the VAFM.

[0044] VAED 500 uses its Resource Map 514 and ports to abstract the
environment from the Value Calculation Methods 508. VAED 500 uses the
Resource Map 514 to map the external ID of a federated instance to the
internal ID of the local instance. When the VAFM 602 downloads a Value
Calculation Method 508 to VAED 500, VAED 500 connects port 509 of the
Value Calculation Method 508 to outgoing ports 518 of VAED 500 according
to Resource Map 514. Resource Map 514 specifies for a given Value
Calculation Method 508, which outgoing port to map to each port of the
Value Calculation Method 508. This mapping may be different for each
instance of the VAED. Each of the outgoing ports contains all of the
information (e.g., address, user id, password) required to connect to the
external data source. By containing different connection information in
the outgoing ports, the various instances of the VAED can communicate
with different instances of a Data Source with total transparency from
the perspective of the Value Calculation Method. The outgoing ports
contain all of the information (e.g., passwords, protocol) needed to
communicate with external data sources. The outgoing ports and Resource
Map must be configured prior to federation, or the federation process
fails.

[0045] FIG. 6 shows process steps for federating virtual attributes 618.
In central Instance Serialize For Federation 610, the instance with the
virtual attribute is bundled up (serialized at 610) with its calculation
methods, and calculation parameters for transportation to the VAEDs.
Next, the manager 602 invokes centrallnstance.getDirectories 612 to get
all of the directories for which the object instance should be federated.

[0046] The process then enters a loop 614 for federating the instance to
all of the directories that apply. For each iteration of the loop, the
manager invokes the directory. federateInstance 616, passing the
serialized instance.

[0047] Inside directory.federateInstance 616, the directory 702 first gets
the ResourceMap 708 needed to map the needs of the federated instance
against the running environment of the VAED. The directory then
deserializes the serialized instance 704 that it was passed and gets its
identifier as shown in FIG. 7. The directory 702 uses the ResourceMap 708
to map the identity of the serialized instance 704 to the local instance
712. The attributeStore 710 retrieves the instance based on the mapped
local ID. The returned local instance then synchronizes parameters and
calculation methods with the deserialized instance 706. The port
requirements are then mapped and the local instance 712 connects the
ports of its calculation method with the ports of the directory.

[0048] FIG. 2 illustrates how federation of multiple instances of a
Virtual Attribute Enabled Directory (VAED) might be coordinated through a
Virtual Attribute Federation Manager (VAFM). The diagram shows how the
VAFM uses a Federated Attribute Interface (FAI) to communicate the
changes of the virtual attributes to the VAED instances. For the sake of
illustration, the VAED instances in this diagram communicate with
different instances of the same Data Source.

[0049] Internally, both the VAFM and VAEDs have attribute stores. The
attribute store of the VAFM 300 (FIG. 3) provides a central location for
the directory object, and its virtual attributes. Structurally the VAFM
attribute store is similar to the VAED attribute store 400 (FIG. 4). VAFM
attribute store 300 (FIG. 3) lacks the AttributeValue for non-virtual
attributes because these values can be propagated through traditional
directory integration techniques. Many relationships are also missing in
the VAFM as they are only needed in a functioning directory. The VAFM
Directory has a serverAddress that the VAFM uses to connect to the VAEDs
that need updating. It may also contain encrypted a user ID and a
password for connecting to the VAEDs.

[0050] The VAED attribute store (FIG. 4) contains the structures needed
for a functional directory. The Directory lacks the serverAddress
attribute since the attribute store resides on a VAED server. An
ObjectInstance can only reside in a single directory in the VAED, while
the VAFM must be able to map an instance to multiple directories.

[0051] Internally, Virtual Attribute Federation System (VAFS) System 104
contains an Attribute Store and a Resource Map 142. VAFS 104 also
contains the federated attributes and calculation methods 606 that
calculate the values of the virtual attributes. VAFS 104 possesses
several measures to protect VAEDs 208/210 against compromised Value
Calculation Method 408, 508. VAFM 304 digitally signs Value Calculation
Method 408, 508 and attributes. If the VAED 600 does not see the proper
signature, it does not execute the Value Calculation Method 408, 508.
Within the VAED, Value Calculation Method 408, 508 executes in a
restricted or "sandbox" environment with the ability to retrieve
information from the Attribute Store 504 or through outgoing ports 518.
This restricted environment prevents the Value Calculation Method 508
from transmitting information outside of the VAED 500 (potentially
leaking information), reading information outside of VAED 500 (except
through the designated ports 518), or changing anything in the Attribute
Store 504. It also prevents the Value Calculation Method 508 from
accessing any information that the executing user identity would not have
access to from outside the VAED 500. These provisions protect the VAED
500 from compromised Value Calculation Methods 408, 508 that might have
been federated from the VAFM. VAED 500 uses its Resource Map 514 and
ports to abstract the environment from the Value Calculation Methods 408,
508. VAED 500 uses the Resource Map 514 to map the external id of a
federated instance to the internal ID of the local instance. When the FIM
downloads a Value Calculation Method 408, 508 to VAED 500, VAED 500
connects the port(s) of Value Calculation Method 408, 508 to external
ports of VAED 500 according to Resource Map 514. Resource Map 514
specifies for a given Value Calculation Method 408, 508, which outgoing
ports 518 to map to each port of the Value Calculation Method 509. This
mapping may be different for each instance of the VAED 500. Each of the
outgoing ports 518 contains all of the information (e.g., address, user
ID, password) required to connect to the external data source. By
containing different connection information in the external ports, the
various instances 208, 210 of the VAED 500 can communicate with different
instances 212, 214 of a Data Source with total transparency from the
perspective of the Value Calculation Method 508. The ports contain all of
the information (e.g,. passwords, protocol) needed to communicate with
external data sources. The external ports 518 and Resource Map 514 must
be configured prior to federation, or the federation process fails.

[0052] FIG. 6 illustrates System 600 having a manager:VAFM 602,
centralinstance:Objectinstance 604, and directory: VAED 606. At 608, a
federateInstance command is initiated from an external trigger to begin
the federation of a given Objectlnstance. The first step in
federateInstances is for the centralInstance:ObjectInstance 604 to be
serialized with a serializeForFederation command 610. At 612, the
centralinstance:Objectinstance 604 receives a getDirectories request 612
and responds with the directories to be updated. The federateInstance
command uses a loop (from 0 until the lastDirectory 614) to
federateInstances 616 to the directories 606 and results are returned at
618.

[0053] It should be understood that the present invention is typically
computer-implemented via hardware and/or software. As such, client
systems and/or servers will include computerized components as known in
the art. Such components typically include (among others) a processing
unit, a memory, a bus, input/output (I/O) interfaces, external devices,
etc.

[0054] While shown and described herein as a system and method for virtual
attribute federation that produces a consistent result at multiple
directories, works in different domains across the enterprise, supports
the retrieval of information from alternate sources in differing IT
environments, supports different directory structures, protects the
directory from compromised calculation methods, and reduces processor and
network load. For example, in one embodiment, the invention provides a
computer-readable/useable virtual attribute federation that produces a
consistent result at multiple directories, works in different domains
across the enterprise, supports the retrieval of information from
alternate sources in differing IT environments, supports different
directory structures, protects the directory from compromised calculation
methods, and reduces processor and network load. To this extent, the
computer-readable/useable medium includes program code that implements
each of the various process steps of the invention. It is understood that
the terms computer-readable medium or computer useable medium comprises
one or more of any type of physical embodiment of the program code. In
particular, the computer-readable/useable medium can comprise program
code embodied on one or more portable storage articles of manufacture
(e.g., a compact disc, a magnetic disk, a tape, etc.), on one or more
data storage portions of a computing device, such as memory and/or
storage system (e.g., a fixed disk, a read-only memory, a random access
memory, a cache memory, etc.), and/or as a data signal (e.g., a
propagated signal) traveling over a network (e.g., during a
wired/wireless electronic distribution of the program code).

[0055] In another embodiment, the invention provides a
computer-implemented method for virtual attribute federation that
produces a consistent result at multiple directories, works in different
domains across the enterprise, supports the retrieval of information from
alternate sources in differing IT environments, supports different
directory structures, protects the directory from compromised calculation
methods, and reduces processor and network load. In this case, a
computerized infrastructure can be provided and one or more systems for
performing the process steps of the invention can be obtained (e.g.,
created, purchased, used, modified, etc.) and deployed to the
computerized infrastructure. To this extent, the deployment of a system
can comprise one or more of (1) installing program code on a computing
device, such as computer system from a computer-readable medium; (2)
adding one or more computing devices to the computer infrastructure; and
(3) incorporating and/or modifying one or more existing systems of the
computer infrastructure to enable the computerized infrastructure to
perform the process steps of the invention.

[0056] As used herein, it is understood that the terms "program code" and
"computer program code" are synonymous and may mean any expression, in
any language, code or notation, of a set of instructions intended to
cause a computing device having an information processing capability to
perform a particular function either directly before or after either or
both of the following: (a) conversion to another language, code or
notation; and/or (b) reproduction in a different material form. To this
extent, program code can be embodied as one or more of: an
application/software program, component software/a library of functions,
an operating system, a basic I/O system/driver for a particular computing
and/or I/O device, and the like.

[0057] In another embodiment, the invention provides a business method
that performs the process steps of the invention on a subscription,
advertising, and/or fee basis. That is, a service provider, such as a
solution integrator, could offer to deploy a computer infrastructure for
virtual attribute federation that produces a consistent result at
multiple directories, works in different domains across the enterprise,
supports the retrieval of information from alternate sources in differing
IT environments, supports different directory structures, protects the
directory from compromised calculation methods, and reduces processor and
network load. In this case, the service provider can create, maintain,
and support, etc., the computer infrastructure by integrating
computer-readable code into a computing system, wherein the code in
combination with the computing system is capable of performing the
process steps of the invention for one or more customers. In return, the
service provider can receive payment from the customer(s) under a
subscription and/or fee agreement and/or the service provider can receive
payment from the sale of advertising content to one or more third
parties.

[0058] The foregoing description of various aspects of the invention has
been presented for purposes of illustration and description. It is not
intended to be exhaustive or to limit the invention to the precise form
disclosed, and obviously, many modifications and variations are possible.
Such modifications and variations that may be apparent to a person
skilled in the art are intended to be included within the scope of the
invention as defined by the accompanying claims.