Embodiments of the present invention relate generally to identity management and access control and more particularly to using a directory enabler and/or profile enabler to support identity management functions.
With the growth of e-business, organizations are wrestling with the challenge of managing secure access to information and applications scattered across a wide range of internal and external computing systems. Furthermore, these organizations need to provide access to a growing number of users, both inside and outside the corporation, without diminishing security or exposing sensitive information. The management of multiple versions of user identities across multiple applications makes the task even more daunting.
Identity management generally includes the concepts of authenticating, i.e., determining that a party is actually who he claims to be, and authorizing, i.e., determining whether a party is authorized or has permission to perform some task, access some resource, etc. Identity management also includes managing attributes e.g., properties, metadata, other identities, preferences, subscriptions, etc., associated with the user. Identity management can also include the notion of anonymizing a user or hiding his identity from those systems or users with which he interacts. However, combining the functions of authentication and authorization with anonymization can be problematic.
Existing methods for combining authentication and authorization with anonymization rely on trust relationships between members of a group or federation. That is, one member of a group may use the authentication and authorization of a user provided by another member of a trusted group. One example of such an arrangement is the use of a single sign-on server. Through a single sign-on server, a user can sign on once and access a number of different servers and/or resources of a group represented by the single sign-on server. Furthermore, the user may be anonymous to the servers of the group. For example, the user may supply his user name and password to the single sign-on server so that he can be authenticated and/or authorized. The single sign-on server may then in turn provide the user with a sign-on identifier or other token that the user can supply to the other servers of the group to prove he is authenticated and/or authorized by the single sign-on server. Since the servers of the group trust the single sign-on server and the tokens supplied by it, the servers can use those tokens rather than the user's other identity information. In this way, the user can remain anonymous to the servers.
However, such trust networks or federations presume that members have perfect knowledge and trust of all other members and require that the network or federation be well established beforehand. This can severely limit the network's ability to expand and handle new users and/or members. The problem is that the federation or “circle of trust” must exist in advance. There is no way for such networks or federations to discover new members as they may be needed or to expand dynamically to handle new members and/or users. That is, current trust relationships must be established and exist before they can be used and there is no way to dynamically discover new members and expand the trust relationship as needed. Hence, there is a need for methods and systems that allow systems to use the existing entities with simple mechanisms to dynamically provide identity management or other services where needed.
Systems, methods, and machine-readable media are disclosed for dynamically providing identity management or other services. In one embodiment, a method of providing a service related to an unknown principal can comprise receiving a request related to the unknown principal. Receiving the request related to the unknown principal can comprise receiving the request from the unknown principal, from a requesting service, or from another entity.
After receiving the request related to the unknown principal, a service to which the principal is known can be located. Locating the service to which the principal is known can be based on one or more identity attributes related to the principal. According to one embodiment, the service can be selected from a list of services based on the identity attributes related to the principal which may include, in some cases, the identity itself. In some cases, the identity attributes related to the principal can be provided by the principal. In one example, an identifier from the principal may itself contain the details, e.g. a URI, of where the service can be located. Alternatively, locating the service to which the principal is known can comprise querying a plurality of services, receiving a response from at least some of the plurality of services indicating whether the principal is known, and selecting a service from the plurality of services based on the response from that service.
Once the service has been located, an identity management result related to the principal can be obtained from the service to which the principal is known. According to one embodiment, the method can further comprise obtaining an identity management result related to the principal from the service to which the principal is known. Obtaining the identity management result related to the principal from the service to which the principal is known can include, but is not limited to, obtaining a security token related to the principal, obtaining an identity attribute related to the principal, changing an identity attribute related to the principal, affecting the principal, etc.
According to another embodiment, a system can comprise a plurality of services adapted to affect or utilize an identity management result and a directory enabler communicatively coupled with one or more of the services. The directory enabler can be adapted to receive a request related to a principal from a requestor to which the principal is unknown, select a service to which the principal is known from the plurality of services based on one or more identity attributes related to the principal, and send information identifying the selected service to the requestor.
According to yet another embodiment, a system can comprise a plurality of services adapted to affect or utilize an identity management result and a profile enabler communicatively coupled with one or more of the services and adapted to receive a request related to a principal. The system can also include a directory enabler communicatively coupled with the profile enabler and adapted to select a service to which the principal is known from the plurality of services based on one or more identity attributes related to the principal.
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments of the present invention. It will be apparent, however, to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown abstracted in block diagram form.
Embodiments of the present invention provide methods, system and machine-readable media for dynamically providing identity management services. Identity management services provided by various embodiments discussed herein include any services related to authentication, authorization, anonymization, or other management and/or control of identity information. Such services can include, for example, authentication services that authenticate an identity of a principal to an end requestor and make assertions in the form of security tokens based on evidence that it trusts. In another example, an identity management service may include an identity attribute service that maintains information or attributes about principals and validates and responds to requests for information about principals. Alternatively or additionally, an identity attribute service can provides attributes or services that report or affect the principal. For example, the service can obtain or retrieve a principal's preferences, location, presence, change the principal's preferences or subscriptions (e.g. add one), or send the principal a message, etc.
As used herein, the term principal refers to a person, system, or other entity capable of making a request to a resource or receiving a request or being affected by services. A principal can have a limited capability such as a browser, or more sophisticated capability such as a web service, for example, when the principal is an application or service provider or other business entity. The term resource is used to refer to a service, application, or other function from which something is accessed by a principal. A security token represents a collection of claims which can include identifiers, aliases, pseudonyms, attributes, etc.
It should be noted that, while discussed herein in terms of an identity management service, embodiments of the present invention are equally applicable to any service providing identity management services and/or any other service related to the principal. For example, the service can provides attributes or services that report or affect the principal. Such services can include but are not limited to obtaining or retrieving a principal's preferences, location, presence, changing the principal's preferences or subscriptions (e.g. add one), sending the principal a message, etc.
Generally speaking, dynamically providing identity management or other services can comprise receiving a request to access a resource from an unknown principal. That is, the principal is anonymized or uses an identity that is not yet known by the target. So, the principal is unknown to the target when request is made. The principal may be either totally or partially unknown to the target. That is, the target may have no knowledge of any identity attributes of the principal or may have knowledge of some identity attributes of the principal but not others. For example, the target may know an identifier or alias of the principal but may not yet know if that identity is authenticated.
An identity management service or other services to which the principal is known, i.e. a service that can complete the missing information about the principal, can be located. According to one embodiment, locating an identity management service or other service to which the principal is known can be based on one or more identity attributes provided by the principal. In some cases, the identity attributes can include an indication of the id itself. As discussed herein, the identity attributes can be considered to include such an indication. However, such an indication is not required. In some cases, the information provided by the principal may include a Universal Resource Identifier (URI) or other information identifying a service to which the principal is known.
In some cases, locating the service to which the principal is known can comprise selecting a service from a stored, queryable, and/or discoverable list of services based on the identity attributes provided by the principal. In other cases, locating the service to which the principal is known can comprise querying a plurality of services, receiving a response from at least some of the plurality of services indicating whether the principal is known, and selecting a service from the plurality of services based on the response from that service.
Once an identity management service or other service to which the principal is known has been located, an identity management result can obtained from the identity management service. For example, in the case of authentication, according to one embodiment, obtaining an identity management result from the identity management service can comprise requesting a security token from the identity management service and receiving the security token from the identity management service. According to an alternative embodiment, obtaining an identity management result from the identity management service can comprise redirecting the principal to the identity management service and receiving the security token from the principal. The method can further comprise determining, based on the security token, whether the principal is authorized to access the requested resource. In response to determining the principal is authorized, the requested resource can be accessed. In other cases, attributes or information can be obtained or affected or the principal can be affected. For example, the service can provide some identity management service such as authentication or other type of service such as obtaining or retrieving a principal's preferences, location, presence, changing the principal's preferences or subscriptions (e.g. add one), sending the principal a message, etc.
Embodiments of the present invention may be implemented in a wide variety of environments and systems. For example, various embodiments may be presented through an Internet web browser and/or a web service. Other types of client-server, peer-to-peer, or other environments are considered to be equally suitable for implementing embodiments of the present invention.
In some embodiments, the system 100 may also include a network 115. The network may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including without limitation TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example, the network 115 maybe a local area network (“LAN”), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (“VPN”); the Internet; an intranet; an extranet; a public switched telephone network (“PSTN”); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks.
The system may also include one or more server computers 120, 125, 130 which can be general purpose computers and/or specialized server computers (including, merely by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers rack-mounted servers, etc.). One or more of the servers (e.g., 130) may be dedicated to running applications, such as a business application, a web server, application server, etc. Such servers may be used to process requests from user computers 105, 110. The applications can also include any number of applications for controlling access to resources of the servers 120, 125, 130.
The web server can be running an operating system including any of those discussed above, as well as any commercially-available server operating systems. The web server can also run any of a variety of server applications and/or mid-tier applications, including HTTP servers, FTP servers, CGI servers, database servers, Java servers, business applications, and the like. The server(s) also may be one or more computers which can be capable of executing programs or scripts in response to the user computers 105, 110. As one example, a server may execute one or more web applications. The web application may be implemented as one or more scripts or programs written in any programming language, such as Java™, C, C# or C++, and/or any scripting language, such as Perl, Python, or TCL, as well as combinations of any programming/scripting languages. The server(s) may also include database servers, including without limitation those commercially available from Oracle, Microsoft, Sybase™, IBM™ and the like, which can process requests from database clients running on a user computer 105, 110.
In some embodiments, an application server may create web pages dynamically for displaying on an end-user (client) system. The web pages created by the web application server may be forwarded to a user computer 105 via a web server. Similarly, the web server can receive web page requests and/or input data from a user computer and can forward the web page requests and/or input data to an application and/or a database server. Those skilled in the art will recognize that the functions described with respect to various types of servers may be performed by a single server and/or a plurality of specialized servers, depending on implementation-specific needs and parameters.
The system 100 may also include one or more databases 135. The database(s) 135 may reside in a variety of locations. By way of example, a database 135 may reside on a storage medium local to (and/or resident in) one or more of the computers 105, 110, 115, 125, 130. Alternatively, it may be remote from any or all of the computers 105, 110, 115, 125, 130, and/or in communication (e.g., via the network 120) with one or more of these. In a particular set of embodiments, the database 135 may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers 105, 110, 115, 125, 130 may be stored locally on the respective computer and/or remotely, as appropriate. In one set of embodiments, the database 135 may be a relational database, such as Oracle 10g, that is adapted to store, update, and retrieve data in response to SQL-formatted commands.
As illustrated here, the system 200 includes a plurality of identity management services 210, 213, and 216. Again, these services 210, 213, and 216 can also be other types of services that provide information about one or more principals, update the information, and/or otherwise affect the principals. These services 210, 213, and 216 may be implemented on separate servers, as illustrated here, and/or in separate domains possibly by different service providers or on the same server, machine, or domain. As introduced above, these services 210, 213, and 216 can include any services related to authentication, authorization, anonymization, or other management and/or control of identity information or otherwise report and/or affect the principal. For example, a service 216 may include an identity attribute service that maintains information or attributes about principals 220-230 known to that service 216 and validates and responds to requests for information about those principals 220-230. Additionally, the services 210, 213, and 216 can control access to one or more resources 211, 212, 214, 215, 217, and 218. The resources 211, 212, 214, 215, 217, and 218 may be maintained within and/or as part of the service as shown here or may be external to the server or service. In either case, the services 210, 213, and 216 can control access to the resource 211, 212, 214, 215, 217, and 218 in conjunction with, instead of, or in addition to the identity management services. In other cases, services 210, 213, and 216 can provides attributes or services that report or affect the principal. For example, the service can obtain or retrieve a principal's preferences, location, presence, change the principal's preferences or subscriptions (e.g. add one), or send the principal a message, etc.
The system 200 can include a directory enabler 205 communicatively coupled with one or more services 210, 213, and 216. Principals 220-230 can be in communication with services 210 and 216 and/or the directory enabler 205. The directory enabler 205 can receive a request directly from a principal 225 or through one of the services 210 with which the principal 220 is in communication. In other words, the principal 220 can act as a requestor of some identity management service. Alternatively, the directory enabler 205 may also receive the request from an application or resource that tries to do identity management, authenticate/authorize the principal, access principal attributes, or affect the attributes or the principal. In such a case, the service or server on which the application executes can be considered the requestor.
So, for example, a principal 220 may request a resource 211 or service 210. As a result, the service 210 may need to access or affect an attribute of the principal 220 or affect the principal 220. In either case, the service 210 may also need to authenticate the principal. However, that principal 220 may be unknown to that service 210. In order to identify the principal 220, the service 210 can pass the request or information from the request, such as identity information from the principal 220, to the directory enabler 205. The identity information from the principal 220 can include, by way of example and not limitation, a user name, alias, or other identifying information.
The directory enabler 205 can then select another one of the services 213 or 216 to whom the principal 220 is known by, for example, prior transactions, etc. In such case, the request to the directory enabler 205 may represent a request to identify which service can provide that function for that principal 220. The directory enabler 205 can include a data store 206 that includes a list of or other information identifying services 210, 213, and 215 of which the directory enabler 205 is aware. In such a case, the directory enabler 205 can be adapted to select the service 216 to which the principal 220 is known from the list of services in the data store 206 based on the identity attributes provided by the principal 220. Alternatively, the directory enabler 205 can be adapted to locate the service 216 to which the principal 220 is known by querying the services 213 and 216 and receiving a response from at least some of the services 213 and 216 indicating whether the principal 220 is known. In such a case, selecting the service 216 can be based on the response from that service 216. Additionally, the directory enabler 205 may be adapted to register the services discovered in such a query and/or register the identities and which service provides what functions for them.
Additionally, it should be noted that these actions may be chained/recurrent. For example, the directory enabler 205 may locate a first service 216 that can provide identity management for the principal 220. The requestor (service or other) can then request that the located service 216 identify a second service 213 that can perform the desired functions. The first service 216 may have the answer or use the directory enabler 205 to answer that question. When the answer is known the result can be return and the original requestor to make the request to the right service provider 213.
According to one embodiment of the present invention, after the directory enabler 205 selects a service 216 to which the principal 220 is known, the service 210, principal 220, or other entity making the request, i.e., the requestor, can request a security token related to the principal 220 from the selected service 216. The requestor, in this case, service 210, can then obtain from the selected service 216 a security token or other information related to the principal 220 that can be used by the requesting service 210 to authenticate the principal 220 and/or authorize the requested access. Alternatively, the requestor may request the selected service 216 to perform some function related to the principal 220 such as access or modify some attributes, obtain or retrieve a principal's preferences, location, presence, change the principal's preferences or subscriptions (e.g. add one), or send the principal a message, etc. In either case, the service 216 may, according to one embodiment, first seek approval from the principal 220 prior to performing any action. That is, the service 216 may contact and inform the principal 220 of a pending access or action and wait for the principal's approval before performing the access or action.
The requesting service 210 can obtain the security token related to the principal 220 from the selected service 216 by, for example, requesting the security token from the selected service 216. In such a case, the requestor can be adapted to receive the security token from the selected service 216. The requesting service 210 can then determine, based on the security token, whether the principal 220 is authorized to access the requested resource 211. In response to determining the principal 220 is authorized, the service 210 can access the requested resource 211. Alternatively, the requesting service 210 can obtain the security token related to the principal 220 from the selected service 216 by redirecting the principal 220 to the selected service 216 to obtain the security token. In such a case, the requesting service 210 can then receive the security token from the principal 220 and determine, based on the security token, whether the principal 220 is authorized to access the requested resource 211. In response to determining the principal 220 is authorized, the service 210 can access the requested resource 211.
According to one embodiment of the present invention, the service 210 making the request to the directory enabler 205 may comprise a policy enforcer as described in U.S. patent application Ser. No. 10/855,999 entitled “Method and Apparatus for Supporting Service Enablers via Service Request Handholding” filed on May 28, 2004 and U.S. patent application Ser. No. 10/856,588 entitled “Method and Apparatus for Supporting Service Enablers via Service Request Composition” filed on May 28, 2004. In such case, the policy enforcer performs orchestration and makes requests to the directory enabler 205 then acts on the results or delegates the action to the profile enabler. Based on policies it may also decide to use the option to redirect the requestor or to make the request itself to the service selected by the directory enabler.
As in the previous example, the services 320, 325, and 330 can control access to one or more resources 321, 322, 326, 327, 331, and 332. The resources 321, 322, 326, 327, 331, and 332 may be maintained within and/or as part of the service as shown here or may be external to the server or service. In either case, the services 320, 325, and 330 can control access to the resource 321, 322, 326, 327, 331, and 332 using the profile enabler 305. Also, as noted previously, the services 320, 325, and 330 can provide identity management services and/or other services that report and/or affect the principal.
It should be noted that while illustrated in
Regardless of exactly how it is implemented, the profile enabler 305 can be adapted to receive a request to access a resource 321, 322, 326, or 327, access a service 325 or 330, affect attributes of a principal, affect a principal, etc. The profile enabler 305 can receive the request directly from the principal 310 or through one of the services with which the principal 310 is in communication. The profile enabler 305 can then forward the request to the directory enabler 340 or request the directory enabler 340 to select a service 320, 325, or 330 to which the principal 310 is known. As in the previous example, this selection can be based on one or more identity attributes provided by the principal 310 such as an alias, user name, or other identifying information. The profile enabler 305 can then obtain a security token related to the principal 310 from the identity management service 325 selected by the directory enabler 340.
So, for example, a principal 310 may request a resource 321 or service from one of the services 320 via the profile enabler 305 or directly from the service 320. In order to identify the principal 310 and determine whether to allow access to the requested resource 321, the profile enabler 305 passes the request or information from the request, such as identity information from the principal 310, to the directory enabler 340. The directory enabler 340 can then select one of the services 325 or 330 to whom the principal 310 is known. The profile enabler 305 can then obtain from the selected service 325 a security token related to the principal 310 that can be used by the requesting service 320 or principal 310 to authenticate the principal 310 and/or authorize the requested access, provide some identity management service or other service, or otherwise affect the principal 310.
As in the previous example, the directory enabler 340 can include a data store 345 that includes directory information identifying services 325 and 330 of which the directory enabler 305 is aware. In such a case, the directory enabler 340 can be adapted to select the service 325 to which the principal 310 is known from the list of services in the data store 345 based on the identity attributes provided by the principal 310. Alternatively, the directory enabler 340 can be adapted to locate the service 325 to which the principal 310 is known by querying, either directly or through the profile enabler 305, the services 325 and 330 and receiving a response from at least some of the services 325 and 330 indicating whether the principal 310 is known. In such a case, selecting the service 325 can be based on the response from that service 325.
Once the directory enabler 340 selects a service 325 to which the principal 310 is known, the profile enabler 305 can obtain a security token or other information related to the principal 310 from the selected service 325 by, for example, requesting the security token from the selected service 325. In such a case, the profile enabler 305 can be adapted to receive the security token from the selected service 325. The requesting service 320 can then determine, based on the security token, whether the principal 310 is authorized to access the requested resource 321 or perform the requested functions. In response to determining the principal 310 is authorized, the service 320 can access the requested resource 321 or perform the requested function. Alternatively, the profile enabler 305 may request the selected service 325 to perform some function related to the principal 310 such as access or modify some attributes, obtain or retrieve a principal's preferences, location, presence, change the principal's preferences or subscriptions (e.g. add one), or send the principal a message, etc. In either case, the service 325 may, according to one embodiment, first seek approval from the principal 310 prior to performing any action. That is, the service 325 may contact and inform the principal 310 of a pending access or action and wait for the principal's approval before performing the access or action.
Alternatively, the profile enabler 305 can obtain the security token related to the principal 310 from the selected service 325 by redirecting the principal 310 to the selected service 325 to obtain the security token. In such a case, the requesting service 320 can then receive the security token from the principal 310 and determine, based on the security token, whether the principal 310 is authorized to access the requested resource 321 or perform the requested function. In response to determining the principal 310 is authorized, the service 320 can access the requested resource 321 or perform the requested function.
Generally speaking, the profile enabler 305 can be used to answer a request about an identity while the directory enabler 340 can identify what service can answer a request about a particular identity. So, the profile enabler 305 accepts a request about an identity and returns the result. The directory enabler 340 finds what services can answer a request about an identity and may explain how to formulate the requests. A separate profile enabler 305, while not necessary, serves the purpose of hiding the directory enabler 340 and possibly other identity information from the requestor.
Therefore, the profile enabler 305 can be used to delegate a task related to a principal 310 that is unknown. For example, a principal 310 or a service 320 can send a message to the profile enabler 305 requesting, for example, to authenticate a particular principal, to locate a particular principal, etc. The profile enabler 305 marshals all the function, either internally or with the directory enabler 340, and/or with a selected services until it has completed the delegated request or failed. That is, the profile enabler 305 can locate a principal or service to which to delegate the task, can send a request for the task to that principal or service, and can receive a response to that request. The profile enabler 305 can then return a result or a status to the requester.
The computer system 400 may additionally include a computer-readable storage media reader 425a, a communications system 430 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory 440, which may include RAM and ROM devices as described above. In some embodiments, the computer system 400 may also include a processing acceleration unit 435, which can include a DSP, a special-purpose processor and/or the like.
The computer-readable storage media reader 425a can further be connected to a computer-readable storage medium 425b, together (and, optionally, in combination with storage device(s) 420) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system 430 may permit data to be exchanged with the network 420 and/or any other computer described above with respect to the system 400.
The computer system 400 may also comprise software elements, shown as being currently located within a working memory 440, including an operating system 445 and/or other code 450, such as an application program (which may be a client application, web browser, mid-tier application, RDBMS, etc.). The application programs may have and/or designed to implement methods of the invention.
It should be appreciated that alternate embodiments of a computer system 400 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed. Software of computer system 400 may include code 450 for implementing any or all of the elements of the systems for locating and providing services as described above with reference to
Generally speaking, a method of providing identity management or other services can comprise receiving a request to access a resource from an unknown principal. A service to which the principal is known can be located. According to one embodiment, locating a service to which the principal is known can be based on one or more identity attributes provided by the principal. In some cases, locating the service to which the principal is known can comprise selecting a service from a stored list of services based on the identity attributes provided by the principal. In other cases, locating the service to which the principal is known can comprise querying a plurality of services, receiving a response from at least some of the plurality of services indicating whether the principal is known, and selecting a service from the plurality of services based on the response from that service.
Two basic scenarios can be considered for illustrative purposes. In one scenario, a principal makes a request of a resource but the resource, or system controlling access to the resource, requires the principal to be authenticated. In a second scenario, a principal makes a request of a resource but, in order to fulfil the request, the resource requires attributes from an identity attribute service. In both scenarios, the principal is invoking a resource that needs identity information pertaining to the principal invoking the resource to process the request. The principal authentication may result in two tokens for the user, an authentication token which represents the completion of an authentication protocol and an identity token which may or may not contain additional information about the principal. Furthermore, the resource relies on the authentication service to perform the authentication.
Methods for performing such services according to embodiments of the present invention will now be discussed with reference to
In this example, the process begins when a requestor, such as a principal, a service, an application, etc. makes a request 505 to the directory enabler to locate a service to perform identity management or other services related to a principal. The requestor can make this request 505 in response to a need to determine something about a principal. For example, the requestor can receive a request from a principal's web browser, from a web service, etc. or may depending upon the implementation. Alternatively, the requestor's logic may need to determine some information about the principal such as obtaining some attributes, performing authentication, etc.
Once the requestor makes the request 505, the directory enabler receives 510 the request from the requestor and locates 515 a service to which the principal is known. As noted above, the directory enabler can include a data store that includes a list of or other information identifying services of which the directory enabler is aware. In such a case, the directory enabler can be adapted to select or locate 515 the service to which the principal is known from the list of services in the data store based on identity attributes provided by the principal. Alternatively, the directory enabler can be adapted to locate 515 the service to which the principal is known by querying the plurality of services and receiving a response from at least some of the plurality of services indicating whether the principal is known. In such a case, selecting 515 the service from the plurality of services can be based on the response from that service.
Optionally, the directory enabler can also determine 520 a format for the requesting services from the selected service. That is, different services may use different formats for requests. Information relating to the type of information, format, etc. may be maintained by the directory enabler, for example, as part of or separate from the data store maintaining information identifying the services. This information, as well as identity information supplied by the principal can be used to determine 520 a format acceptable to the selected service.
Once the directory enabler selects 515 an identity management service to which the principal is known and possibly determines 520 a format for a request to that service, the directory enabler can send 525 the information about the service to the requestor. The requestor in turn receives 530 the service information from the directory enabler and can send 535 a request to that service. For example, the requestor can request the selected service to perform some identity management service for the principal or perform some other function(s) that affect and/or report the principal.
Optionally, the requestor may receive 540, in response, a security token or other information related to the principal from the selected service. According to one embodiment, the requestor can then determine 545, based on the security token or other information, whether the principal is authorized to, for example, access a requested resource or perform a requested function. In response to determining 545 the principal is authorized, the requested resource can be accessed 550 or a requested function can be performed.
In this example, the process begins when a requestor, such as a principal, a service, an application, etc. makes a request 605 to the directory enabler to locate a service to perform identity management or other services related to a principal. The requestor can make this request 605 in response to a need to determine something about a principal. For example, the requestor can receive a request from a principal's web browser, from a web service, etc. or may depending upon the implementation. Alternatively, the requestor's logic may need to determine some information about the principal such as obtaining some attributes, performing authentication, etc.
Once the requestor makes the request 605, the directory enabler receives 610 the request from the requestor and locates 615 a service to which the principal is known. As noted above, the directory enabler can include a data store that includes a list of or other information identifying services of which the directory enabler is aware. In such a case, the directory enabler can be adapted to select or locate 615 the service to which the principal is known from the list of services in the data store based on identity attributes provided by the principal. Alternatively, the directory enabler can be adapted to locate 615 the service to which the principal is known by querying the plurality of services and receiving a response from at least some of the plurality of services indicating whether the principal is known. In such a case, selecting 615 the service from the plurality of services can be based on the response from that service.
Optionally, the directory enabler can also determine 620 a format for the requesting services from the selected service. That is, different services may use different formats for requests. Information relating to the type of information, format, etc. may be maintained by the directory enabler, for example, as part of or separate from the data store maintaining information identifying the services. This information, as well as identity information supplied by the principal can be used to determine 620 a format acceptable to the selected service.
Once the directory enabler selects 615 an identity management service to which the principal is known and possibly determines 620 a format for a request to that service, the directory enabler can send 625 the information about the service to the requestor. The requestor in turn receives 630 the service information from the directory enabler and can redirect 635 the principal or other entity to that service. For example, the requestor can redirect the principal or other entity to the selected service to perform some identity management service for the principal or perform some other function(s) that affect and/or report the principal.
Optionally, the requestor may receive 640, in response, a security token or other information related to the principal from the principal or other entity redirected to the selected service. According to one embodiment, the requestor can then determine 645, based on the security token or other information, whether the principal is authorized to, for example, access a requested resource or perform a requested function. In response to determining 645 the principal is authorized, the requested resource can be accessed 650 or a requested function can be performed.
In this example, the process begins when a requestor, such as a principal, a service, an application, etc. makes a request to the profile enabler to locate a service to perform identity management or other services related to a principal. The profile enabler can in turn receive 705 the request and send 710 the request or information from the request, such as identity information related to the principal, to the directory enabler.
Once the profile enabler sends the request, the directory enabler receives 715 the request from the profile enabler and locates 720 a service to which the principal is known. As noted above, the directory enabler can include a data store that includes a list of or other information identifying services of which the directory enabler is aware. In such a case, the directory enabler can be adapted to select or locate 720 the service to which the principal is known from the list of services in the data store based on identity attributes provided by the principal. Alternatively, the directory enabler can be adapted to locate 720 the service to which the principal is known by querying the plurality of services, either directly or through the profile enabler, and receiving a response from at least some of the plurality of services indicating whether the principal is known. In such a case, selecting 720 the service from the plurality of services can be based on the response from that service.
Optionally, the directory enabler can also determine 725 a format for the requesting services from the selected service. That is, different services may use different formats for requests. Information relating to the type of information, format, etc. may be maintained by the directory enabler, for example, as part of or separate from the data store maintaining information identifying the services. This information, as well as identity information supplied by the principal can be used to determine 725 a format acceptable to the selected service.
Once the directory enabler selects 720 a service to which the principal is known and possibly determines 725 a format for a request to that service, the directory enabler can send 730 the information about the service to the profile enabler. The profile enabler in turn sends 735 a request or information about the principal to that service. For example, the profile enabler can request the selected service to perform some identity management service for the principal or perform some other function(s) that affect and/or report the principal.
Optionally, the profile enabler may receive 740, in response, a security token or other information related to the principal from the selected service. According to one embodiment, the profile enabler can then determine 745, based on the security token or other information, whether the principal is authorized to, for example, access a requested resource or perform a requested function. In response to determining 745 the principal is authorized, the profile enabler can return 750 a result to the requestor indicating that the requested resource can be accessed or a requested function can be performed.
In this example, the process begins when a requestor, such as a principal, a service, an application, etc. makes a request to the profile enabler to locate a service to perform identity management or other services related to a principal. The profile enabler can in turn receive 805 the request and send 810 the request or information from the request, such as identity information related to the principal, to the directory enabler.
Once the profile enabler sends the request, the directory enabler receives 815 the request from the profile enabler and locates 820 a service to which the principal is known. As noted above, the directory enabler can include a data store that includes a list of or other information identifying services of which the directory enabler is aware. In such a case, the directory enabler can be adapted to select or locate 820 the service to which the principal is known from the list of services in the data store based on identity attributes provided by the principal. Alternatively, the directory enabler can be adapted to locate 820 the service to which the principal is known by querying the plurality of services, either directly or through the profile enabler, and receiving a response from at least some of the plurality of services indicating whether the principal is known. In such a case, selecting 820 the service from the plurality of services can be based on the response from that service.
Optionally, the directory enabler can also determine 825 a format for the requesting services from the selected service. That is, different services may use different formats for requests. Information relating to the type of information, format, etc. may be maintained by the directory enabler, for example, as part of or separate from the data store maintaining information identifying the services. This information, as well as identity information supplied by the principal can be used to determine 825 a format acceptable to the selected service.
Once the directory enabler selects 820 a service to which the principal is known and possibly determines 825 a format for a request to that service, the directory enabler can send 830 the information about the service to the profile enabler. The profile enabler in turn redirects 835 the requestor to that service. For example, the profile enabler can redirect the requestor to the selected service to perform some identity management service for the principal or perform some other function(s) that affect and/or report the principal.
Optionally, the profile enabler may receive 840, in response, a security token or other information related to the principal from the requestor. According to one embodiment, the profile enabler can then determine 845, based on the security token or other information, whether the principal is authorized to, for example, access a requested resource or perform a requested function. In response to determining 845 the principal is authorized, the profile enabler can return 850 a result to the requestor indicating that the requested resource can be accessed or a requested function can be performed.
The profile enabler can then locate 910 a principal or service to which to delegate the task. That is, the profile enabler can select a service or identify another principal to which the principal identified by the request is known. As discussed above, the service or principal to which the principal is known can be located by the profile enabler and/or the directory enabler based on information provided by the requestor. For example, the request may include identity information related to the principal, a URI for the service or principal to be used, etc.
The profile enabler can then send 915 a request for the task to that principal or service, and can receive 920 a response indicating results of the task. For example, the results may indicate authentication of the principal, completion or failure of a requested identity management task, etc. The profile enabler can then return 925 the result or a status for the results to the requester.
In the foregoing description, for the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate embodiments, the methods may be performed in a different order than that described. It should also be appreciated that the methods described above may be performed by hardware components or may be embodied in sequences of machine-executable instructions, which may be used to cause a machine, such as a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the methods. These machine-executable instructions may be stored on one or more machine readable mediums, such as CD-ROMs or other type of optical disks, floppy diskettes, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, flash memory, or other types of machine-readable mediums suitable for storing electronic instructions. Alternatively, the methods may be performed by a combination of hardware and software.
While illustrative and presently preferred embodiments of the invention have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art.
The present application is a divisional of U.S. patent application Ser. No. 11/330,963 filed Jan. 11, 2006, the entire contents of which is incorporated herein by reference for all purposes.
Number | Name | Date | Kind |
---|---|---|---|
4484306 | Kulczycky et al. | Nov 1984 | A |
4956769 | Smith | Sep 1990 | A |
4961224 | Yung | Oct 1990 | A |
5077666 | Brimm et al. | Dec 1991 | A |
5113499 | Ankney et al. | May 1992 | A |
5226143 | Baird et al. | Jul 1993 | A |
5428795 | Johnson et al. | Jun 1995 | A |
5455953 | Russell | Oct 1995 | A |
5530861 | Diamant et al. | Jun 1996 | A |
5557742 | Smaha et al. | Sep 1996 | A |
5581691 | Hsu et al. | Dec 1996 | A |
5678041 | Baker et al. | Oct 1997 | A |
5689679 | Jouppi | Nov 1997 | A |
5692125 | Schloss et al. | Nov 1997 | A |
5708780 | Levergood et al. | Jan 1998 | A |
5757920 | Misra et al. | May 1998 | A |
5764890 | Glasser et al. | Jun 1998 | A |
5765153 | Benantar et al. | Jun 1998 | A |
5793966 | Amstein et al. | Aug 1998 | A |
5802518 | Karaev et al. | Sep 1998 | A |
5812776 | Gifford | Sep 1998 | A |
5819271 | Mahoney et al. | Oct 1998 | A |
5826029 | Gore, Jr. et al. | Oct 1998 | A |
5842212 | Ballurio et al. | Nov 1998 | A |
5872969 | Copeland et al. | Feb 1999 | A |
5875461 | Lindholm | Feb 1999 | A |
5889952 | Hunnicutt et al. | Mar 1999 | A |
5892903 | Klaus | Apr 1999 | A |
5893149 | Hagersten et al. | Apr 1999 | A |
5903878 | Talati et al. | May 1999 | A |
5907621 | Bachman et al. | May 1999 | A |
5908469 | Botz et al. | Jun 1999 | A |
5924096 | Draper et al. | Jul 1999 | A |
5940394 | Killian | Aug 1999 | A |
5944780 | Chase et al. | Aug 1999 | A |
5944824 | He | Aug 1999 | A |
5978779 | Stein et al. | Nov 1999 | A |
5991771 | Falls et al. | Nov 1999 | A |
5991810 | Shapiro et al. | Nov 1999 | A |
5991881 | Conklin et al. | Nov 1999 | A |
5999911 | Berg et al. | Dec 1999 | A |
6005571 | Pachauri et al. | Dec 1999 | A |
6012059 | Neimat et al. | Jan 2000 | A |
6026474 | Carter et al. | Feb 2000 | A |
6028605 | Conrad et al. | Feb 2000 | A |
6029195 | Herz | Feb 2000 | A |
6032227 | Shaheen et al. | Feb 2000 | A |
6041357 | Kunzelman et al. | Mar 2000 | A |
6058381 | Nelson | May 2000 | A |
6058480 | Brown | May 2000 | A |
6061799 | Eldridge et al. | May 2000 | A |
6064656 | Angal et al. | May 2000 | A |
6073109 | Flores et al. | Jun 2000 | A |
6073174 | Montgomerie et al. | Jun 2000 | A |
6081518 | Bowman-Amuah | Jun 2000 | A |
6088679 | Barkley | Jul 2000 | A |
6088796 | Cianfrocca et al. | Jul 2000 | A |
6098056 | Rusnak et al. | Aug 2000 | A |
6112228 | Earl et al. | Aug 2000 | A |
6119167 | Boyle et al. | Sep 2000 | A |
6131120 | Reid | Oct 2000 | A |
6133916 | Bukszar et al. | Oct 2000 | A |
6134658 | Multerer et al. | Oct 2000 | A |
6138104 | Marchak et al. | Oct 2000 | A |
6141778 | Kane et al. | Oct 2000 | A |
6151531 | Frankel et al. | Nov 2000 | A |
6154741 | Feldman | Nov 2000 | A |
6157925 | Jenkins et al. | Dec 2000 | A |
6157942 | Chu et al. | Dec 2000 | A |
6158010 | Moriconi et al. | Dec 2000 | A |
6163844 | Duncan et al. | Dec 2000 | A |
6170013 | Murata | Jan 2001 | B1 |
6178418 | Singer | Jan 2001 | B1 |
6182086 | Lomet et al. | Jan 2001 | B1 |
6182142 | Win et al. | Jan 2001 | B1 |
6185608 | Hon et al. | Feb 2001 | B1 |
6185650 | Boonie et al. | Feb 2001 | B1 |
6192476 | Gong | Feb 2001 | B1 |
6208986 | Schneck et al. | Mar 2001 | B1 |
6212558 | Antur et al. | Apr 2001 | B1 |
6212640 | Abdelnur et al. | Apr 2001 | B1 |
6216199 | DeKoning et al. | Apr 2001 | B1 |
6226752 | Gupta et al. | May 2001 | B1 |
6230185 | Salas et al. | May 2001 | B1 |
6233576 | Lewis | May 2001 | B1 |
6233618 | Shannon | May 2001 | B1 |
6240360 | Phelan | May 2001 | B1 |
6240414 | Beizer et al. | May 2001 | B1 |
6243816 | Fang et al. | Jun 2001 | B1 |
6253248 | Nakai et al. | Jun 2001 | B1 |
6256739 | Skopp et al. | Jul 2001 | B1 |
6266420 | Langford et al. | Jul 2001 | B1 |
6275944 | Kao et al. | Aug 2001 | B1 |
6282546 | Gleichauf et al. | Aug 2001 | B1 |
6286098 | Wenig et al. | Sep 2001 | B1 |
6289462 | McNabb et al. | Sep 2001 | B1 |
6301668 | Gleichauf et al. | Oct 2001 | B1 |
6311269 | Luckenbaugh et al. | Oct 2001 | B2 |
6314492 | Allen et al. | Nov 2001 | B1 |
6321338 | Porras et al. | Nov 2001 | B1 |
6324656 | Gleichauf et al. | Nov 2001 | B1 |
6338097 | Krenzke et al. | Jan 2002 | B1 |
6339423 | Sampson et al. | Jan 2002 | B1 |
6345266 | Ganguly et al. | Feb 2002 | B1 |
6347312 | Byrne et al. | Feb 2002 | B1 |
6347374 | Drake et al. | Feb 2002 | B1 |
6357010 | Viets et al. | Mar 2002 | B1 |
6366913 | Fitler, Jr. et al. | Apr 2002 | B1 |
6374359 | Shrader et al. | Apr 2002 | B1 |
6381579 | Gervais et al. | Apr 2002 | B1 |
6385653 | Sitaraman et al. | May 2002 | B1 |
6393569 | Orenshteyn | May 2002 | B1 |
6415321 | Gleichauf et al. | Jul 2002 | B1 |
6421682 | Craig et al. | Jul 2002 | B1 |
6421781 | Fox et al. | Jul 2002 | B1 |
6430688 | Kohl et al. | Aug 2002 | B1 |
6434531 | Lancelot et al. | Aug 2002 | B1 |
6442567 | Retallick et al. | Aug 2002 | B1 |
6453342 | Himmel et al. | Sep 2002 | B1 |
6457047 | Chandra et al. | Sep 2002 | B1 |
6460141 | Olden | Oct 2002 | B1 |
6463418 | Todd | Oct 2002 | B1 |
6463509 | Teoman et al. | Oct 2002 | B1 |
6466932 | Dennis et al. | Oct 2002 | B1 |
6470386 | Combar et al. | Oct 2002 | B1 |
6487663 | Jaisimha et al. | Nov 2002 | B1 |
6499107 | Gleichauf et al. | Dec 2002 | B1 |
6507847 | Fleischman | Jan 2003 | B1 |
6513056 | Copeland et al. | Jan 2003 | B1 |
6516416 | Gregg et al. | Feb 2003 | B2 |
6519643 | Foulkes et al. | Feb 2003 | B1 |
6519648 | Eyal | Feb 2003 | B1 |
6526438 | Bienvenu et al. | Feb 2003 | B1 |
6526447 | Giammaria | Feb 2003 | B1 |
6536037 | Guheen et al. | Mar 2003 | B1 |
6539379 | Vora et al. | Mar 2003 | B1 |
6539382 | Byrne et al. | Mar 2003 | B1 |
6539396 | Bowman-amuah | Mar 2003 | B1 |
6542993 | Erfani | Apr 2003 | B1 |
6557039 | Leong et al. | Apr 2003 | B1 |
6578147 | Shanklin et al. | Jun 2003 | B1 |
6584548 | Bourne et al. | Jun 2003 | B1 |
6584569 | Reshef | Jun 2003 | B2 |
6591347 | Tischler et al. | Jul 2003 | B2 |
6598058 | Bird et al. | Jul 2003 | B2 |
6609205 | Bernhard et al. | Aug 2003 | B1 |
6615218 | Mandal et al. | Sep 2003 | B2 |
6618806 | Brown et al. | Sep 2003 | B1 |
6629132 | Ganguly et al. | Sep 2003 | B1 |
6636891 | LeClair et al. | Oct 2003 | B1 |
6640307 | Viets et al. | Oct 2003 | B2 |
6647393 | Dietterich et al. | Nov 2003 | B1 |
6668322 | Wood et al. | Dec 2003 | B1 |
6675261 | Shandony | Jan 2004 | B2 |
6678828 | Pham et al. | Jan 2004 | B1 |
6680942 | Mead et al. | Jan 2004 | B2 |
6691232 | Wood et al. | Feb 2004 | B1 |
6697849 | Carlson | Feb 2004 | B1 |
6708170 | Byrne et al. | Mar 2004 | B1 |
6711632 | Chow et al. | Mar 2004 | B1 |
6718328 | Norris | Apr 2004 | B1 |
6741992 | McFadden | May 2004 | B1 |
6742126 | Mann et al. | May 2004 | B1 |
6745221 | Ronca | Jun 2004 | B1 |
6748447 | Basani et al. | Jun 2004 | B1 |
6754696 | Kamath et al. | Jun 2004 | B1 |
6757708 | Craig et al. | Jun 2004 | B1 |
6763370 | Schmeidler et al. | Jul 2004 | B1 |
6765864 | Natarajan et al. | Jul 2004 | B1 |
6772214 | McClain et al. | Aug 2004 | B1 |
6775704 | Watson et al. | Aug 2004 | B1 |
6779120 | Valente et al. | Aug 2004 | B1 |
6782379 | Lee | Aug 2004 | B2 |
6804221 | Magret et al. | Oct 2004 | B1 |
6859834 | Arora et al. | Feb 2005 | B1 |
6868406 | Ogg et al. | Mar 2005 | B1 |
6879995 | Chinta et al. | Apr 2005 | B1 |
6901433 | San Andres et al. | May 2005 | B2 |
6957237 | Traversat et al. | Oct 2005 | B1 |
7003587 | Battat et al. | Feb 2006 | B1 |
7080077 | Ramamurthy et al. | Jul 2006 | B2 |
7124203 | Joshi et al. | Oct 2006 | B2 |
7134137 | Joshi et al. | Nov 2006 | B2 |
7185364 | Knouse et al. | Feb 2007 | B2 |
7194764 | Martherus et al. | Mar 2007 | B2 |
7231661 | Villavicencio et al. | Jun 2007 | B1 |
7249369 | Knouse et al. | Jul 2007 | B2 |
7290288 | Gregg et al. | Oct 2007 | B2 |
7346923 | Atkins et al. | Mar 2008 | B2 |
20010037469 | Gupta et al. | Nov 2001 | A1 |
20010054153 | Wheeler et al. | Dec 2001 | A1 |
20020026563 | Chamberlain et al. | Feb 2002 | A1 |
20020032684 | Kobayashi et al. | Mar 2002 | A1 |
20020091745 | Ramamurthy et al. | Jul 2002 | A1 |
20020091798 | Joshi et al. | Jul 2002 | A1 |
20020099671 | Mastin Crosbie et al. | Jul 2002 | A1 |
20020112083 | Joshi et al. | Aug 2002 | A1 |
20020112155 | Martherus et al. | Aug 2002 | A1 |
20020112185 | Hodges | Aug 2002 | A1 |
20020116642 | Joshi et al. | Aug 2002 | A1 |
20020120599 | Knouse et al. | Aug 2002 | A1 |
20020129116 | Humphrey | Sep 2002 | A1 |
20020165960 | Chan | Nov 2002 | A1 |
20030061272 | Krishnamurthy et al. | Mar 2003 | A1 |
20030074580 | Knouse et al. | Apr 2003 | A1 |
20030145074 | Penick | Jul 2003 | A1 |
20030149737 | Lambert et al. | Aug 2003 | A1 |
20030158897 | Ben-Natan et al. | Aug 2003 | A1 |
20030191846 | Hunnicutt et al. | Oct 2003 | A1 |
20040117665 | Ong | Jun 2004 | A1 |
20050124320 | Ernst et al. | Jun 2005 | A1 |
20060021010 | Atkins et al. | Jan 2006 | A1 |
20060236382 | Hinton et al. | Oct 2006 | A1 |
20070162581 | Maes | Jul 2007 | A1 |
Entry |
---|
Clear Trust, Unified Access Management, Securant Technologies, Inc., 1997, pp. 1-23. |
SiteMinder Agent Operations Guide, Version 4.0, Netegrity Inc., 1997, pp. 1-174. |
SiteMinder Installation Guide, Version 4.0, Netegrity Inc., 1997, pp. 1-280. |
SiteMinder Deployment Guide, Version 4.0, Netegrity Inc., 1997, pp. 1-314. |
SiteMinder Developer's API Guide, Version 4.0, Netegrity Inc., 1997, pp. 1-368. |
SiteMinder Policy Server Operations Guide, Version 4.0, Netegrity Inc., 1997, pp. 1-556. |
Active Directory Collection, Microsoft TechNet, Mar. 28, 2003, p. 1. |
Appendix B—ACL File Syntax, Sun Microsystems, Inc., iPianet Web Server: FastTrack Edition Administrator's Guide, Jul. 13, 2000, 7 pages. |
Chapter 12—Controlling Access to Your Server, Sun Microsystems, Inc., iPianet Web Server: FastTrack Edition Administrator's Guide, Jul. 13, 2000, 24 pages. |
Chapter 2 Syntax and Use of obj.conf, Sun Microsystems, Inc., iPianet Web Server, FastTrack Edition NSAPI Programmer's Guide, Jul. 20, 2000, 16 pages. |
DNS—Contents, http://www2.rad.com/networks/1998/dns/main.htm, Dec. 7, 1999, 15 pages. |
HP Introduces Next-Generation Web Authorization Products for E-Business, Hewlett-Packard, Press Release, Jan. 18, 1999, 3 pages. |
HP Introduces Security for Microsoft NT Extranets, Portals and E-Services, Hewlett-Packard, Press Release, Jan. 17, 2000, 3 pages. |
HP Provides Unprecedented Range of Authentication Options, Hewlett-Packard, Press Release, Sep. 1, 1999, 3 pages. |
Introduction to SSL, Netscape Communications Corporation, http://developer.netscape.com/docs/manuals/security/sslin/contents.htm, Oct. 9, 1998, 12 pages. |
Oblix CSA Solution Administration Guide, Oblix, Inc., Version 3.5, 1999, 328 pages. |
U.S. Appl. No. 09/792,911, Advisory Action mailed on Aug. 9, 2005, 3 pages. |
U.S. Appl. No. 09/792,911, Final Office Action mailed on May 9, 2005, 17 pages. |
U.S. Appl. No. 09/792,911, Non-Final Office Action mailed on Dec. 2, 2005, 13 pages. |
U.S. Appl. No. 09/792,911, Non-Final Office Action mailed on Sep. 9, 2004, 18 pages. |
U.S. Appl. No. 09/792,915, Advisory Action mailed on Jun. 23, 2006, 4 pages. |
U.S. Appl. No. 09/792,915, Final Office Action mailed on Jun. 30, 2005, 18 pages. |
U.S. Appl. No. 09/792,915, Final Office Action mailed on Mar. 8, 2005, 19 pages. |
U.S. Appl. No. 09/792,915, Final Office Action mailed on Apr. 3, 2006, 20 pages. |
U.S. Appl. No. 09/792,915, Non-Office Action mailed on Jul. 23, 2004, 10 pages. |
U.S. Appl. No. 09/792,915, Non-Final Office Action mailed on Oct. 4, 2005, 17 pages. |
U.S. Appl. No. 09/792,918, Advisory Action mailed on Sep. 20, 2005, 3 pages. |
U.S. Appl. No. 09/792,918, Final Office Action mailed on Jun. 21, 2005, 16 pages. |
U.S. Appl. No. 09/792,918, Non-Final Office Action mailed on Sep. 8, 2004, 22 pages. |
U.S. Appl. No. 09/792,934, Final Office Action mailed on Jun. 2, 2005, 10 pages. |
U.S. Appl. No. 09/792,934, Non-Final Office Action mailed on Sep. 21, 2004, 19 pages. |
U.S. Appl. No. 09/792,934, Non-Final Office Action mailed on Aug. 19, 2005, 5 pages. |
U.S. Appl. No. 09/793,196, Advisory Action mailed on Jul. 21, 2005, 3 pages. |
U.S. Appl. No. 09/793,196, Final Office Action mailed on May 31, 2006, 11 pages. |
U.S. Appl. No. 09/793,196, Final Office Action mailed on Mar. 8, 2005, 13 pages. |
U.S. Appl. No. 09/793,196, Non-Final Office Action mailed on Nov. 21, 2006, 11 pages. |
U.S. Appl. No. 09/793,196, Non-Final Office Action mailed on Dec. 13, 2005, 12 pages. |
U.S. Appl. No. 09/793,196, Non-Final Office Action mailed on Jul. 14, 2004, 13 pages. |
U.S. Appl. No. 09/793,320, Advisory Action mailed on Jun. 7, 2006, 3 pages. |
U.S. Appl. No. 09/793,320, Final Office Action mailed on Mar. 17, 2006, 18 pages. |
U.S. Appl. No. 09/793,320, Final Office Action mailed on May 10, 2005, 19 pages. |
U.S. Appl. No. 09/793,320, Office Action mailed on Sep. 20, 2005, 15 pages. |
U.S. Appl. No. 09/793,320, Non-Final Office Action mailed on Aug. 4, 2004, 18 pages. |
U.S. Appl. No. 09/793,354, Advisory Action mailed on Dec. 15, 2005, 3 pages. |
U.S. Appl. No. 09/793,354, Final Office Action mailed on Apr. 19, 2004, 9 pages. |
U.S. Appl. No. 09/793,354, Final Office Action mailed on Aug. 26, 2005, 9 pages. |
U.S. Appl. No. 09/793,354, Non-Final Office Action mailed on Jan. 4, 2005, 8 pages. |
U.S. Appl. No. 09/793,354, Non-Final Office Action mailed on Oct. 1, 2003, 12 pages. |
U.S. Appl. No. 09/793,355, Advisory Action mailed on May 2, 2006, 3 pages. |
U.S. Appl. No. 09/793,355, Advisory Action mailed on Jun. 21, 2005, 7 pages. |
U.S. Appl. No. 09/793,355, Final Office Action mailed on Feb. 9, 2006, 15 pages. |
U.S. Appl. No. 09/793,355, Final Office Action mailed on Apr. 6, 2005, 16 pages. |
U.S. Appl. No. 09/793,355, Non-Final Office Action mailed on Mar. 12, 2004, 13 pages. |
U.S. Appl. No. 09/793,355, Non-Final Office Action mailed on Sep. 7, 2005, 13 pages. |
U.S. Appl. No. 09/793,658, Advisory Action mailed on Jan. 31, 2006, 3 pages. |
U.S. Appl. No. 09/793,658, Final Office Action mailed on Nov. 2, 2005, 16 pages. |
U.S. Appl. No. 09/793,658, Non-Final Office Action mailed on Sep. 9, 2004, 14 pages. |
U.S. Appl. No. 09/814,091, Advisory Action mailed on Jul. 5, 2005, 3 pages. |
U.S. Appl. No. 09/814,091, Final Office Action mailed on Apr. 8, 2005, 24 pages. |
U.S. Appl. No. 09/814,091, Non-Final Office Action mailed on Nov. 1, 2005, 18 pages. |
U.S. Appl. No. 09/814,091, Non-Final Office Action mailed on Jul. 14, 2004, 22 pages. |
U.S. Appl. No. 09/814,091, Non-Final Office Action mailed on May 3, 2006, 7 pages. |
U.S. Appl. No. 09/886,515, Final Office Action mailed on Feb. 14, 2006, 36 pages. |
U.S. Appl. No. 09/886,515, Non-Final Office Action mailed on Sep. 7, 2006, 27 pages. |
U.S. Appl. No. 09/886,515, Non-Final Office Action mailed on Dec. 28, 2004, 35 pages. |
U.S. Appl. No. 09/886,515, Non-Final Office Action mailed on Aug. 29, 2005, 35 pages. |
U.S. Appl. No. 11/330,963, Final Office Action mailed on Nov. 16, 2010, 23 pages. |
U.S. Appl. No. 11/330,963, Final Office Action mailed on Jun. 12, 2009, 28 pages. |
U.S. Appl. No. 11/330,963, Non-Final Office Action mailed on May 26, 2010, 20 pages. |
U.S. Appl. No. 11/330,963, Non-Final Office Action mailed on Apr. 22, 2011, 25 pages. |
U.S. Appl. No. 11/330,963, Non-Final Office Action mailed on Feb. 19, 2008, 26 pages. |
U.S. Appl. No. 11/542,311, Final Office Action mailed on Sep. 11, 2007, 14 pages. |
U.S. Appl. No. 11/542,311, Non-Final Office Action mailed on Jun. 8, 2007, 12 pages. |
Barrett, Diary of a Break-And-Enter, Cyber Style, Technology in Government, Jan. 2000, 22 pages. |
Cholter et al., I BAN: Intrusion Blocker Based on Active Networks, Proceedings of the DARPA Active Networks Conference and Exposition (DANCE'02), 2002, 11 pages. |
Cooney, IBM Rolls Out Host- and Server-Based Mgmt. Apps, Network World, Framingham, vol. 12, Iss. 6, Feb. 6, 1995, pp. 6-7. |
Easter, Method to Report Access Control of LAN Server Resources on a Per User Basis, IBM Technical Disclosure Bulletin, Apr. 1992, 172 Pages. |
Good, The LDAP Data Interchange Format (LDIF)—Technical Specification, RFC 2849, Jun. 2000, 14 pages. |
Hayes, Policy-Based Authentication and Authorization: Secure Access to the Network Infrastructure, IEEE ACSAC '00 Proceedings of the 16th Annual Computer Security Applications Conference, Dec. 2000, pp. 328-333. |
Hitchens, et al., Design Choices for Symmetric Key Based Inter-domain Authentication Protocols in Distributed Systems, Computer Security Applications Conference, 12th Annual, Dec. 9-13, 1996, pp. 105-116. |
Hodges et al., Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security, RFC 2830, May 2000, 12 pages. |
Howard et al., An Approach for using LDAP as a network Information Service, RFC 2307, Mar. 1998, 20 pages. |
Janis, Reference Monitor-Creating Group Membership: IBM Technical Disclosure Bulletin, Mar. 1990, 431 pages. |
Kim et al., Improving Cross-domain Authentication over Wireless Local Area Networks, Security and Privacy for Emerging Areas in Communications Networks, 2005 (SecureComm 2005; First International Conference, Sep. 5-9, 2005, pp. 127-138. |
Leon, McAfee's NetTools Promises to Ease Network Desktop Diagnosis, InfoWorld, San Mateo, vol. 17, Issue 30, Jul. 24, 1995, 53 pages. |
Lin et al., A Wireless-based Authentication and Anonymous Channels for Large Scale Area, Computers and Communications, Proceedings; Sixth IEEE Symposium, Jul. 3-5, 2001, pp. 36-41. |
Luciani et al., Server Cache Synchronization Protocol (SCSP), RFC 2334, Apr. 1998, 39 pages. |
Musthaler , The Trouble with Help Desk Selection, Network World, Framingham, vol. 12, Issue 8, Feb. 20, 1995, pp. 35-39. |
Mwakalinga et al., Authorization System in Open Networks based on Attribute Certificates, http://www.dsv.su.se/-matei/courses/3%20-%202i1272/L3b.pdf., Feb. 20, 2007, 17 pages. |
Park et al., Secure Cookies on the Web, IEEE Internet Computing, Jul./Aug. 2002, pp. 36-44. |
Pfitzmann et al., Analysis of Liberty Single-Sign-On With Enabled Clients, IEEE Internet Computing, vol. 7, Issue 6, Nov./Dec. 2003, pp. 38-44. |
Phipatanasuphorn et al., Vulnerability of Sensor Networks to Unauthorized Traversal and Monitoring, IEEE Transactions on Computers, vol. 53, No. 3, Mar. 2004, pp. 364-369. |
Piscitello et al., Project Guards Laptop and Desktop Data, InfoWorld, Jun. 21, 1999, pp. 48 and 54. |
Schmersal, Testing to maintain service standards, Communications News, Nokomis, vol. 35, Issue 3, Mar. 1999, pp. 22-23. |
Skaggs et al., Network Vulnerability Analysis, IEEE, 2002, pp. III-493-III-495. |
Stokes et al., Access Control Requirements for LDAP, RFC 2820, May 2000, 9 pages. |
Wahl et al., Authentication Methods for LDAP, RFC 2829, May 2000, 16 pages. |
Wahl et al., Lightweight Directory Access Protocol (v3), RFC 2251, Dec. 1997, 48 pages. |
Walsh, Remedy releases three applications for help-desk suite, InfoWorld, San Mateo, vol. 19, Issue 16, Apr. 21, 1997, 34 pages. |
Wilde et al., XPath, Xlink, XPointer, and XML: A Practical Guide to Web Hyperlinking and Transclusion, Chapter 3 Section 2, Addison Wesley Professional, Jul. 23, 2002. |
Wu et al., Personalization With Dynamic Profiler, Proceedings of the Third International Workshop on Advanced Issues of E-Commerce and Web-Based Information Systems, Jun. 2001, pp. 12-20. |
Yaacovi et al., Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services, RFC 2589, May 1999, 12 pages. |
Number | Date | Country | |
---|---|---|---|
20140075531 A1 | Mar 2014 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11330963 | Jan 2006 | US |
Child | 14081578 | US |