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

Abstract:

Methods and apparatus, including computer program products, implementing
and using techniques for providing user credentials over a network to a
remote computer application. User credentials for the remote computer
application are stored in a central repository that is accessible through
the network. A request is sent to a service to perform, on behalf of a
user, a particular task involving the remote computer application. It is
determined whether the service has been granted permission to act on
behalf of the user with respect to the remote computer application. When
the service has permission to act on behalf of the user, the service is
used to retrieve the user's credentials for the remote computer
application from the central repository and to supply the retrieved user
credentials to the remote computer application.

Claims:

1. An interoperability network configured to facilitate messaging and
mediate policy differences among a plurality of independent services and
users having associated client machines, the interoperability network
comprising one or more computing devices configured to: receive a request
for a first service to perform a particular task involving a second
service on behalf of a first user, wherein the first and second services
are in communication with an interoperability network and are provided by
first and second independent service providers, respectively; determine
whether the first user has provided a first set of credentials that
defines access information for the second service, the first set of
credentials being included among a plurality of sets of credentials
stored on one or more storage media accessible through the
interoperability network; determine whether the first service is
authorized to act on behalf of the first user with respect to the second
service with reference to one or more of a plurality of permissions
stored on the one or more storage media; and where the first user has
provided the first set of credentials, and where the first service is
authorized to act on behalf of the first user with respect to the second
service, authorizing the first service to perform the particular task
involving the second service on behalf of the first user.

2. The network of claim 1, wherein each of the plurality of sets of
credentials defines access information for a corresponding user for a
corresponding service in communication with the interoperability network.

3. The network of claim 1, wherein each of the plurality of sets of
credentials is of a type that is specified by the respective service, and
at least two of the plurality of sets of credentials correspond to
different authentication protocols.

4. The network of claim 1, wherein determining whether the first service
has been granted permission to act on behalf of the first user with
respect to the second service comprises: retrieving a first policy from a
plurality of policies stored on the one or more storage media, the first
policy defining first conditions under which the first service is
authorized to act on behalf of the first user with respect to the second
service; and determining whether the particular task complies with the
first policy.

5. The network of claim 1, wherein first set of credentials is stored in
a first user's credential storage area on the one or more storage media,
the first user's credential storage area storing a plurality of sets of
credentials for the first user that each defines access information for
the first user for one or more services accessible via the
interoperability network.

6. The network of claim 1, wherein determining whether the first service
is authorized to act on behalf of the first user with respect to the
second service comprises determining whether the first service has been
granted a read permission.

7. The network of claim 1, wherein the first user is either an individual
user or an organization representing one or more users.

8. The network of claim 1, wherein at least some of the independent
services communicate with the interoperability network via different
access points on a public network.

9. A method for facilitating communications via an interoperability
network configured to facilitate messaging and mediate policy differences
among a plurality of independent services and users having associated
client machines, the method comprising: receiving a request for a first
service to perform a particular task involving a second service on behalf
of a first user, wherein the first and second services are in
communication with an interoperability network and are provided by first
and second independent service providers, respectively; determining
whether the first user has provided a first set of credentials that
defines access information for the second service, the first set of
credentials being included among a plurality of sets of credentials
stored on one or more storage media accessible through the
interoperability network; determining whether the first service is
authorized to act on behalf of the first user with respect to the second
service with reference to one or more of a plurality of permissions
stored on the one or more storage media; and where the first user has
provided the first set of credentials, and where the first service is
authorized to act on behalf of the first user with respect to the second
service, authorizing the first service to perform the particular task
involving the second service on behalf of the first user.

10. The method of claim 9, wherein each of the plurality of sets of
credentials defines access information for a corresponding user for a
corresponding service in communication with the interoperability network.

11. The method of claim 9, wherein each of the plurality of sets of
credentials is of a type that is specified by the respective service, and
at least two of the plurality of sets of credentials correspond to
different authentication protocols.

12. The method of claim 9, wherein determining whether the first service
has been granted permission to act on behalf of the first user with
respect to the second service comprises: retrieving a first policy from a
plurality of policies stored on the one or more storage media, the first
policy defining first conditions under which the first service is
authorized to act on behalf of the first user with respect to second
service; and determining whether the particular task complies with the
first policy.

13. The method of claim 9, wherein first set of credentials is stored in
a first user's credential storage area on the one or more storage media,
the first user's credential storage area storing a plurality of sets of
credentials for the first user that each defines access information for
the first user for one or more services accessible via the
interoperability network.

14. The method of claim 9, wherein determining whether the first service
is authorized to act on behalf of the first user with respect to the
second service comprises determining whether the first service has been
granted a read permission.

15. The method of claim 9, wherein the first user is either an individual
user or an organization representing one or more users.

16. The method of claim 9, wherein at least some of the independent
services communicate with the interoperability network via different
access points on a public network.

17. A computer readable storage medium storing instructions for
facilitating communications via an interoperability network configured to
facilitate messaging and mediate policy differences among a plurality of
independent services and users having associated client machines, the
instructions comprising: first instructions for receiving a request for a
first service to perform a particular task involving a second service on
behalf of a first user, wherein the first and second services are in
communication with an interoperability network and are provided by first
and second independent service providers, respectively; second
instructions for determining whether the first user has provided a first
set of credentials that defines access information for the second
service, the first set of credentials being included among a plurality of
sets of credentials stored on one or more storage media accessible
through the interoperability network; third instructions for determining
whether the first service is authorized to act on behalf of the first
user with respect to the second service with reference to one or more of
a plurality of permissions stored on the one or more storage media; and
fourth instructions for, where the first user has provided the first set
of credentials, and where the first service is authorized to act on
behalf of the first user with respect to the second service, authorizing
the first service to perform the particular task involving the second
service on behalf of the first user.

18. The computer readable medium of claim 17 wherein each of the
plurality of sets of credentials defines access information for a
corresponding user for a corresponding service in communication with the
interoperability network.

19. The computer readable medium of claim 17, wherein each of the
plurality of sets of credentials is of a type that is specified by the
respective service, and at least two of the plurality of sets of
credentials correspond to different authentication protocols.

20. The computer readable medium of claim 17, wherein determining whether
the first service has been granted permission to act on behalf of the
first user with respect to the second service comprises: retrieving a
first policy from a plurality of policies stored on the one or more
storage media, the first policy defining first conditions under which the
first service is authorized to act on behalf of the first user with
respect to the second service; and determining whether the particular
task complies with the first policy.

[0002] This invention relates to access control for computing systems.

[0003] Computer security, especially regarding access to sensitive data,
is typically done by granting access rights to individual users. As a
prerequisite, the user must provide some sort of proof of identity,
typically through a password or a digital certificate, such as a
Verisign® X.509 certificate. Other ways to provide a proof of identity
include using secure digital keys, various types of biometric
identification, or different combinations of authentication methods.

[0004] An individual person typically has identity credentials associated
with several different systems. In order to ease the process of
authenticating to these different systems, the concepts of single sign-on
(SSO) and federated identity have been introduced to allow a single set
of identity credentials be used for authentication against several
applications. At the current time, the SSO and federated identity take
one of two schemes.

[0005] The first scheme, which is often referred to as the "desktop
wallet" scheme, typically has two modes. In the first mode, all
applications needing authentication are installed on the same computer
and the user has stored authentication credentials into a local
credential store on the computer. When the user signs in to a local SSO
application on the computer, the authentication credentials are retrieved
from the local credential store and are subsequently handed to each of
the local applications, as needed. In the second mode of the "desktop
wallet" scheme, the SSO application supports HTTP (Hyper Text Transfer
Protocol) and HTML (Hyper Text Markup Language) form authentication. In
this second mode, the applications are remote, but when the user's local
browser encounters a web page needing credentials known to the desktop
wallet, the SSO application fills in the required values. The browser
then transfers the credentials to the remote application.

[0006] In the desktop wallet model, the user has full control of which
credentials the SSO application can access and what operations the SSO
application is allowed to conduct with the credentials. Examples of the
desktop wallet scheme can be found in many shareware, freeware, or
shrink-wrapped products supporting single sign-on. The desktop wallet
model is sometimes also used in applications that contain single sign-on
features, even though the applications themselves may not solely be
single sign-on applications

[0007] In the second scheme, which often is referred to as "federated
identity," no credentials are stored on the user's computer. Instead,
different services or applications that are accessible over the Internet
store the user's credentials. The different services or applications can
have different sets of credentials for the same user. The applications
participate in an identity federation, that is, the applications use a
shared protocol that allows any one (or possibly many) of the user's
credentials for an individual application or service to be used by other
systems within the federated realm. The federated identity scheme thus
allows a user to authenticate herself to one application or service, and
then if the user would like to authenticate herself to a second service,
the second service can automatically query the first service about
whether the user's authentication was approved. If the user's
authentication was approved by the first service, the second service can
automatically approve the user without requiring a second authentication
from the user. The user can also decide whether to exclude any services
or applications from the federated identity network, for example, in the
event that the user does not trust a particular service or application
which is part of the federated identity network. Examples of the
federated identity network authentication scheme can be found in concepts
such as Microsoft's® Passport and in the protocols developed by the
Liberty Alliance® project.

[0008] Although the above solutions typically are sufficient in situations
where the different applications are installed on the same machine, and
where the applications collaborate in a federated identity network using
a shared protocol, there are many situations in which a user needs to
access applications on computers or systems that do not collaborate in a
federated identity network. Such situations cannot be addressed with the
above-mentioned solutions, and the user is thus forced to individually
sign on to each application, possibly with different sets of user
credentials for each application. This can be both time-consuming and
challenging for the user to remember, in particular if the user has
multiple credentials set up for different applications and services.

[0009] In view of the above, there is a need for providing a solution that
enables a user to do a single authentication or sign-on to multiple
applications or services that are not installed on the same computer and
that do not belong to a common federated identity network. In particular,
there is a need to enable various protocol bindings (including third
party additions to the protocol binding set) and to maintain
confidentiality of the individual user's credentials in such a dynamic
environment.

SUMMARY

[0010] In general, in one aspect, the invention provides methods and
apparatus, including computer program products, implementing and using
techniques for providing user credentials over a network to a remote
computer application. User credentials for the remote computer
application are stored in a central repository that is accessible through
the network. A request is sent to a service to perform, on behalf of a
user, a particular task involving the remote computer application. It is
determined whether the service has been granted permission to act on
behalf of the user with respect to the remote computer application. When
the service has permission to act on behalf of the user, the service is
used to retrieve the user's credentials for the remote computer
application from the central repository and to supply the retrieved user
credentials to the remote computer application.

[0011] Advantageous implementations can include one or more of the
following features. The user credentials for a user can be stored in a
credential storage area of the central repository, where the credential
storage area is associated with a user account for the user. The user's
credential storage area can include one or more sets of user credentials,
where each set of user credentials corresponds to a particular remote
computer application and is of a type that is specified by the remote
computer application. The remote computer application can include a
description of what type of user credentials are needed from a user in
order to access and use the remote computer application. The service can
be associated with a particular addressable endpoint on the network that
has the same name as the remote computer application with which the
service is associated. Permission can be granted to a provider of the
service to read one or more sets of user credentials from the user's
credential storage area of the central repository. Determining whether
the service has been granted permission can include determining whether
the provider of the service has been granted read access to the
corresponding set of user credentials in the user's credential storage
area of the central repository.

[0012] A policy can be determined for under what circumstances the service
is authorized to act on behalf of the user with respect to the remote
computer application, and permission can be granted to a provider of the
service to read one or more sets of user credentials from the user's
credential storage area of the central repository only when the policy is
not violated. Determining whether the service has been granted permission
can include determining whether the policy is violated or not, and
determining whether the provider of the service has been granted read
access to the corresponding set of user credentials in the user's
credential storage area of the central repository. The user can be an
individual user or an organization representing one or more users. The
network can be an interoperability network including functionality for
routing messages through the interoperability network and functionality
for mediating differences in communication protocol formats between
users, services, and computer applications associated with the
interoperability network.

[0013] In general, in another aspect, the invention provides a system for
providing user credentials over a network to a remote computer
application. The system includes a network, a central repository and a
service. The network connects network nodes that each represents a user,
a service, or a computer application. The central repository is
accessible through the network and stores user credentials for the
computer application. The service receives a request to perform, on
behalf of a user, a particular task involving the computer application;
determines whether the service has been granted permission to act on
behalf of the user with respect to the computer application; and when the
service has permission to act on behalf of the user, retrieves the user's
credentials for the computer application from the central repository and
to supply the retrieved user credentials to the computer application.

[0014] Advantageous implementations can include one or more of the
following features. The central repository can include several credential
storage areas for storing user credentials, where each credential storage
area is associated with a user account for the user. The user's
credential storage area can include one or more sets of user credentials,
where each set of user credentials corresponds to a particular computer
application and being of a type that is specified by the computer
application. The computer application can include a description of what
type of user credentials are needed from a user in order to access and
use the remote computer application. The service can be associated with a
particular addressable endpoint on the network and can have the same as
the computer application with which the service is associated. The system
can include a read permission granted to a provider of the service to
read one or more sets of user credentials from the user's credential
storage area of the central repository. The service can determine whether
the service has been granted permission by determining whether the
provider of the service has been granted the read permission.

[0015] The system can include a policy stating under what circumstances
the service is authorized to act on behalf of the user with respect to
the remote computer application; and a read permission granted to a
provider of the service to read one or more sets of user credentials from
the user's credential storage area of the central repository only when
the policy is not violated. The service can determine whether the service
has been granted permission by determining whether the policy is violated
or not, and determining whether the provider of the service has been
granted read access to the corresponding set of user credentials in the
user's credential storage area of the central repository. The user can be
an individual user or an organization representing one or more users. The
network can be an interoperability network including functionality for
routing messages through the interoperability network and functionality
for mediating differences in communication protocol formats between
users, services, and computer applications associated with the
interoperability network.

[0016] In general, in another aspect, the invention provides methods and
apparatus, including computer program products, implementing and using
techniques for providing user credentials over a network to a plurality
of remote computer applications. Several sets of user credentials for a
user are stored in a central repository that is accessible through the
network. Each set of user credentials represents information that is
required by a remote computer application to uniquely identify the user.
A single sign on to the network is performed using a single set of user
credentials for the user. Several requests are sent to several services,
where each request is a request to perform, on behalf of a user, a
particular task involving a particular remote computer application
associated with the service. For each service that receives a request, it
is determined whether the service has been granted permission to act on
behalf of the user with respect to the associated remote computer
application. For each service that has permission to act on behalf of the
user, the service is used to retrieve the user's credentials for the
associated remote computer application from the central repository and to
supply the retrieved user credentials to the remote computer application.

[0017] In general, in another aspect, the invention provides a system for
providing user credentials over a network to a plurality of computer
applications. The system includes a network, a central repository, a
login module, and several services. The network connects several network
nodes, where each network node represents one or more of: a user, a
service, and a computer application. The central repository is accessible
through the network and stores several sets of user credentials for a
user. Each set of user credentials represents information that is
required by a remote computer application to uniquely identify the user.
The login module receives a single sign on to the network from the user,
which uses only single set of user credentials for the user. Each
service, receives a request to perform, on behalf of a user, a particular
task involving a particular computer application associated with the
service; determines whether the service has been granted permission to
act on behalf of the user with respect to the computer application; and
when the service has permission to act on behalf of the user, retrieves
the user's credentials for the particular computer application from the
central repository and to supply the retrieved user credentials to the
computer application.

[0018] The details of one or more implementations of the invention are set
forth in the accompanying drawings and the description below. Other
features, objects, and advantages of the invention will be apparent from
the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

[0019]FIG. 1 shows a schematic diagram of a system in which the invention
can be implemented.

[0020]FIG. 2 shows a flowchart for a process that illustrates the
operation of the single sign on functionality of the interoperability
network of FIG. 1.

[0021] Like reference symbols in the various drawings indicate like
elements.

DETAILED DESCRIPTION

[0022] The present invention provides methods and apparatus for
accomplishing a secure identity federation for non-federated systems on
an extensible, dynamically routed network. As a result, a user can do a
single sign on to the network, and the user's various credentials that
are needed by the non-federated systems can be automatically supplied to
the systems without the user having to sign on to any individual systems
or services. Individual users can retain control over which providers can
access the users' credentials, and can manage their own trust
relationships according to the functionality they desire. The value of
federated identity is provided without requiring the participating
applications to implement any particular identity federation protocol. At
the same time, due credential security is maintained without limiting the
flexibility of providers to produce innovative solutions upon the
network.

[0023] The invention will now be described in detail by way of example and
with reference to specific implementations including the best modes
contemplated by the inventors for carrying out the invention. Examples of
these specific implementations are illustrated in the accompanying
drawings. While the invention is described in conjunction with these
specific implementations, it will be understood that it is not intended
to limit the invention to the described implementations. On the contrary,
it is intended to cover alternatives, modifications, and equivalents as
may be included within the spirit and scope of the invention. In the
following description, specific details are set forth in order to provide
a thorough understanding of the present invention. The present invention
may be practiced without some or all of these specific details. In
addition, well known features or details may not have been described to
avoid unnecessarily obscuring the invention.

[0024] As shown in FIG. 1, a system (100) in which the invention can be
implemented includes one or more users (102), such as individuals or
different types of organizations. The users (102) communicate over a
communications network (104), such as the Internet, with an
interoperability network (106). The interoperability network (106), which
will be described in further detail below, contains functionality for
facilitating interoperability between users (102) and various
applications (108; 110), such as (but not limited to) web services. The
interoperability network (106) contains a repository (112) in which the
users' credentials for the various applications (108; 110) are securely
stored. The storage, access, and use of the users' credentials from the
repository (112) will be discussed in further detail below.

[0025] The interoperability network (106) facilitates interoperability
using, among other things, a wide variety of web services technologies
and standards including, for example, Simple Object Access Protocol
(SOAP), Web Services Description Language (WSDL), WS-Security, WS-Policy,
and Business Process Execution Language (BPEL). One of the core tasks of
the interoperability network (106) is to mediate the technology
differences in data formats, communications protocols and business
policies through a set of established and defined policies.

[0026] In general, the term web services refers to a collection of
technology standards that enable software applications of all types to
communicate over a network. A web service typically facilitates a
connection between two applications or services in which queries and
responses are exchanged in XML (eXtended Markup Language) over HTTP (or
HTTPS). More specifically, the term web services implies the
implementation of a stack of specific, complementary standards.

[0027] Although not specifically tied to any transport protocol, web
services build on Internet connectivity and infrastructure to ensure
nearly universal reach and support. In particular, web services take
advantage of HTTP, the same connection protocol used by Web servers and
browsers. XML (and its corresponding semantics) is a widely accepted
format for exchanging data and is a fundamental building block for nearly
every other layer in the web services stack. SOAP is a protocol for
messaging between applications. The SOAP protocol is based on XML and
uses common Internet transport protocols like HTTP to carry its data.
WSDL is an XML-based description of how to connect to and communicate
with a particular web service. A WSDL description abstracts a particular
service's various connections and messaging protocols into a high-level
bundle. UDDI (Universal Description, Discovery and Integration)
represents a set of protocols and a public directory for the registration
and real-time lookup of web services and other business processes. The
WSDL description forms a key element of the UDDI directory's service
discovery model. Various implementations of the invention employ these
and similar technologies to provide interoperability between and among
disparate platforms, services or applications as a service.

[0028] Specific mechanisms by which interoperability networks (106) can
facilitate interaction among a variety of entities will now be described
with reference to the accompanying figures. It will be understood that
the mechanisms described are merely examples of techniques that can be
employed to facilitate the basic functionalities of such interoperability
networks. That is, any technologies that facilitate "on-demand" access to
a wide range of services are within the scope of the invention.

[0029] In a specific example, a service (or set of services) (108; 110) is
provisioned by one or more service providers in conjunction with the
interoperability network (106). During the provisioning process,
connection format and security preferences can be specified for messages
received by the services (108; 110), as further described below. In one
implementation, provisioning includes setting up a service configuration
such that the service can be used by the interoperability network (106).
As part of this set up, the services (108; 110) can specify the type of
message format they prefer to receive. The respective services (108; 110)
can reside either inside or outside the firewall of their service
providers.

[0030] In some implementations, the service provider can optionally
specify which users (102) or services (108; 110) can access the
provisioned service (108; 110) and the conditions under which the users
or services can have access. It should be recognized that the services
(108; 110) can be provided by the provider to any type of entity such as,
for example, an individual user from a particular organization or a
particular organizational entity. An organization can represent a
distinct business entity, a particular user or set of users of a business
entity, or an administrative domain of a computer application.

[0031] As used herein, the term "service" represents any computer
application, process, entity, or device accessible to other applications,
processes, entities, or devices through an interface such as an
application programming interface (API), user interface, or Internet web
user interface by any of a variety of protocols over a network within an
entity or over the Internet. A service can also include multiple methods
or applications on a single device or distributed across multiple
devices.

[0032] A service provider can provision any number and type of services
(108; 110). Also, any number and type of service providers can provision
services (108; 110) to be accessed through the interoperability network
(106). Accordingly, the interoperability network (106) can be configured
to provision multiple services (108; 110) from multiple service
providers.

[0033] After services (108; 110) are provisioned, messages can be sent
between two or more services (108; 110) through the interoperability
network (106). For example, a user (102) associated with a first device
can access a particular service (108; 110) on a second device through the
interoperability network (106) using a communication process (or service)
located on the first device.

[0034] The interoperability network (106) can include any number of
mechanisms for mediating communications between two or more services
(108; 110). In the illustrated implementation, the interoperability
network (106) includes a mechanism for translating messages sent between
the services, such as from application A (108) to application B (110).
Messages can use formats such as MIME (Multipurpose Internet Mail
Extensions), DIME (Direct Internet Message Encapsulation), and the like,
with AS2 (Applicability Statement 2), SOAP, and other application
bindings. MIME and DIME are attachment/part formats, while SOAP and AS2
are application logic binding protocols. Of course, a message can use any
suitable type of protocol, structuring, or formatting specification,
which results in a particular format for the message. When different
entities, such as application A (108) and application B (110), use
different formats for their messages, the interoperability network (106)
translates the messages such that recipients receive the messages in the
appropriate format. In addition to translation of messages, any number of
other enrichments can be applied to messages in the interoperability
network (106). Such enrichments can include, for example, a digital
signature service, a tariff calculator for a purchase order, and so on.

[0035] According to various implementations, the services (108; 110) and
their service providers need not be aware of the message format
requirements of the message destination, nor of any format translation
taking place in the interoperability network (106). Application A (108)
can send the message as if Application B (110) employed the same message
format as used by Application A (108).

[0036] The repository (112) or directory of the interoperability network
(106) can store, in addition to the user credentials, various information
regarding the services (108; 110) and entities that provision and/or use
such services. This information can include, for example, user
identities, service identities, and policies that control what entities
associated with the interoperability network (106) can interact, and the
manner in which they can interact. The interoperability network (106)
preferably also includes mechanisms for creating and combining services
(108; 110), registering users (102) and their identifying information,
and handling messages routed between services (108; 110) and/or users
(102). The repository (112) can be formed from one or more databases or
directory services, including databases or directory services using LDAP
(Lightweight Directory Access Protocol), or the like stored on one or
more memory devices on one or more computing platforms.

[0037] In some implementations of the invention, the interoperability
network (106) provides security management including authentication,
authorization and security policy enforcement using the information in
the directory (112) and policy framework. The interoperability network
(106) can perform security management at various points in a message's
network lifecycle, for example, when a message is sent into the
interoperability network (106) from a service (108; 110), when the
message is routed to its destination endpoint, and when the message is
delivered out of the interoperability network (106) to its destination
service (108; 110). While the following discussion employs the term
"service," it will be understood that this is intended to include all
application and software entities capable of connecting to and
interacting with the interoperability network (106).

[0038] Authentication is the process of verifying that users (102) or
services (108; 110) interacting through the interoperability network
(106) have valid network identities. The authentication process can also
involve the interoperability network (106) supplying credentials required
by the service (108; 110) to identify the interoperability network (106).
Authorization is the process of making sure a service (108; 110) has
permission to exchange messages with another service (108; 110). Security
policy enforcement allows services to specify the level of security other
services must employ to interact with them through the interoperability
network (106). For example, if a first service (108) has a security
policy of required encryption for data and required password
authentication or better, then only services connecting to the
interoperability network (106) with a connection security policy that
requires at least data encryption will be allowed to exchange messages
with the first service. Service providers of services can define
equivalent security policies, allowing the interoperability network (106)
to consider certain policies to be equivalent to others, though they are
not the same, for the purpose of gaining access to services.

[0039] According to a specific implementation, a service identity is the
network service address of an interoperability network endpoint to which
the connecting service wants to be associated. The service proof is the
password configured for the associated endpoint. The user identity is a
combination of organization and user name. Optionally a service name can
be provided with the user identity. The user identity associates the
connecting service with the corresponding network user account.

[0040] When a service posts a message to the network or polls for a
message, the service initiates a connection to the interoperability
network (106). The service is authenticated and associated with an
endpoint (114) on the interoperability network (106). The
interoperability network (106) verifies that the connection security
policy of the connecting service (108; 110) is at least as high as the
connection security policy defined by the associated endpoint (114). If
the authentication and security policy checks pass for a posted message,
the message is accepted into the interoperability network (106) and is
ready to be routed. Otherwise the message is not accepted and a SOAP
fault is returned to the service (108; 110). If the service is polling
for a message and verification succeeds, the message requested by the
poll is delivered to the service. If security verification fails, a SOAP
fault is returned to the service and the polled for message is not
delivered.

[0041] When connecting to the interoperability network (106) the service
(108; 110) supplies a username that identifies the service as an identity
on the interoperability network (106). The provided identity associates
the connecting service (108; 110) with an endpoint service (114) on the
interoperability network (106). In addition, the service supplies a
password and/or a client certificate as proof of that identity. In the
case of HTTPS connections, the interoperability network (106) provides a
server certificate that can be used by the service (108; 110) for
authentication of the interoperability network (106).

[0042] As mentioned above, each service must connect with a security level
that is the same or higher than the connection security policy configured
for the service's associated endpoint service which can be configured,
for example, for HTTP, HTTPS (HTTP with encryption) or HTTPS with
certificate-based authentication.

[0043] The interoperability network (106) determines the endpoint (114)
associated with a message and routes the message to a message queue
associated with that endpoint (114). During this routing phase, security
policy and permission verification is performed. If the security policy
and permission verification passes, the message is routed to the message
queue associated with the destination endpoint (114). If either part of
the verification does not pass, the message is not routed and a SOAP
fault is returned to the service (108; 110) that originated the message.

[0044] Security policies are enforced in a bi-directional manner. That is
the security policy of the connecting service's endpoint (i.e., the
origin endpoint) and the security policy of the destination service's
endpoint (i.e., the destination endpoint) must both be met. For example,
if the origin endpoint has a security policy of HTTP, it will allow
services that use HTTP or HTTPS to connect. However, the only endpoints
the origin endpoint will be allowed to message with are endpoints with a
security policy that allows HTTP. That is, endpoints with a security
policy of HTTPS or higher will not allow services that connect with HTTP
to message with the service associated with them.

[0045] Permission enforcement can also be performed during the message
routing phase. The destination endpoint has a permissions or access
control list policy that is stored in the directory that the network
references to determine whether or not the origin endpoint is allowed to
exchange messages with this destination endpoint.

[0046] When the interoperability network (106) pushes a message to a
destination service, the interoperability network (106) can perform
authentication of the service (108; 110), can provide authentication
credentials to the service (108; 110), and will enforce the connection
security policy configured for the endpoint (114) corresponding to the
destination service. If authentication verification and security policy
validation succeed, the message is delivered to the destination service.
If either security verifications fail, the message is not delivered and a
SOAP fault is returned to the service that originated the message.

[0047] When connecting from the interoperability network (106) to a
destination service, the interoperability network (106) can be configured
to provide no authentication credentials, to supply a username and/or
password, or to authenticate a digital certificate (e.g., a Verisign®
X.509 certificate) sent by the destination service to the
interoperability network (106). In addition, the interoperability network
(106) can be configured to supply a digital certificate, which the
destination service can use to authenticate the interoperability network
(106). It will be understood that the foregoing description relating to
security management is merely exemplary and that any suitable
alternatives for providing any combination of the described
functionalities are within the scope of the invention.

[0048] In order to accomplish a secure single sign-on (SSO) capability
within the interoperability network (106) a novel integration is formed
of the above-described protocol transformation and access control
capabilities that are present in the interoperability network (106). In
addition, the routing meta-data associated with messages and permission
definition sets are extended to support the added functionality.
Furthermore, a credential storage area is associated with each user
account in the repository (112) of the interoperability network (106).

[0049] As was seen above, applications (108; 110) can be defined within
the interoperability network (106). The applications (108; 110) are
identified with a unique name, for example, "Application A" (108) and
"Application B" (110). Each application (108; 110) contains a description
of what type of authentication credentials are needed from a user (102)
in order to access and use the application (108; 110).

[0050] For each application (108; 110) that a user would like to access,
the user creates an application identity (AppIdentity) entry within the
credential storage area that is associated with the user's account in the
interoperability network's repository (112). The AppIdentity entry
contains the particular credentials for the user (102) for the particular
application (108; 110) and must be of the type specified by the
application (108; 110). For example, if Application A (108) requires a
first string containing a username and a second string containing a
password, the user (102) would enter his username and password in his
AppIdentity entry in the repository (112). Thus, in the simplified system
(100) shown in FIG. 1, a user (102) would have one AppIdentity entry for
Application A (108), and another AppIdentity entry for Application B
(110) stored in the user's credential storage area of the repository
(112). The AppIdentity entry for a particular application (108; 110) can
be created and stored in the repository (112) when the user (102) sets up
a user account or otherwise provides his credentials to the application
(108; 110) for the first time. Alternatively, the AppIdentity entry can
be set up in the repository (112) at a later time for applications that
have already received the user credentials.

[0051] Separately from the user's AppIdentity entries and the
applications, a service provider can create a service on the
interoperability network (106) that authenticates a user (102) and
performs authorized work on behalf of the user (102). In one
implementation, such a service is referred to as application instance
(AppInstance) and is associated with a particular endpoint (114) on the
interoperability network (106). The AppInstance is associated with a
particular application (108; 110) through the unique name of the
application (108; 110).

[0052] In one implementation, the AppInstance also designates one or more
application owners (AppOwner) within the service provider's organization.
The AppOwner is a special type of user account on the interoperability
network (106), and its role in the SSO solution will be described in
further detail below. Finally, a special permission is introduced to the
interoperability network (106), which will be referred to below as ActAs.
An exemplary interaction between the user (102), the application (108;
110), the AppInstance, the AppOwner, the ActAs permission, and the
AppIdentity entry will now be explained.

[0053] When a user (102) that has created and stored an AppIdentity entry
in the repository (112) for a particular application, for example,
Application A (108), decides that she trusts a particular service
provider to act on her behalf and perform certain operations involving
Application A (108), the user (102) grants an ActAs permission to the
service provider's organization. The process of granting the ActAs
permission is a standard process, similar to granting a read or edit
permission against resources. The main difference with the ActAs
permission is the actions that the ActAs permission allows, rather than
the manner in which the ActAs permission is granted or revoked. By
receiving the ActAs permission, each AppOwner within the provider's
organization is granted read permission to the AppIdentity entry for
Application A that is stored in the user's credential store in the
repository (112) and corresponds to Application A (108). In one
implementation, the ActAs permission can be a general permission to the
service provider's organization to act on the user's behalf and perform
certain operations involving any applications for which the user (102)
has stored credentials in the repository (112).

[0054]FIG. 2 shows a flowchart for a process (200) that illustrates the
operation of the SSO functionality of the interoperability network at
runtime. In FIG. 2, it is assumed that the user is signed on to the
interoperability network (106) and previously has set up AppIdentity
credentials for a particular application, such as Application A (108). It
is further assumed that Application A (108) has an associated AppInstance
that is provided at an endpoint (114) by a service provider on the
interoperability network (106), and that the user (102) wishes to send a
message to Application A (108) through this associated AppInstance.

[0055] As can be seen in FIG. 2, the process begins by a message being
received by the AppInstance (step 202). As is the case for all messages
that travel through the interoperability network (106), the message
contains associated metadata that includes, among other things,
information identifying the user (102) that submitted the message. Next,
the AppInstance invokes the AppOwner that is associated with the
AppInstance to attempt to retrieve the user's credentials for Application
A (step 204). The AppOwner knows where to search for the credential
information, since the received message has an associated user identity,
and the AppInstance contains the application name, that is, "Application
A," which is identical to the name of the corresponding AppIdentity entry
in the repository (112).

[0056] The process then checks whether the user (102) associated with the
message has an AppIdentity entry in her credential store that has the
same unique name as the application (step 206). If the user has an
AppIdentity with the same unique name as the application, the process
continues to step 208, which will be described below. If the user does
not have an AppIdentity with the same unique name as the application, the
process continues to step 210, where the AppOwner is informed that no
credentials exist for the user.

[0057] When the process determines in step 206 that an AppIdentity entry
with the same name as the application exists, the process checks whether
the user (102) has granted the ActAs permission to the AppOwner (step
208). If the user (102) has granted the ActAs permission to the AppOwner,
then the process returns the user's credentials to the requesting
AppOwner (step 214), which in turn passes the credentials to the invoking
AppInstance (step 216). This means that the AppInstance is now permitted
to perform work authorized by the user (102) with respect to Application
A (108), and ends the authentication process. If it is determined in step
208 that the user (102) has not granted any ActAs permission to the
AppOwner for the AppInstance, the process continues to inform the
AppOwner that no ActAs permission has been granted (step 212) and the
AppOwner returns this information to the invoking AppInstance, after
which the process ends. Optionally, the user (102) can be informed
whenever an AppOwner attempts to retrieve credentials from her credential
store in the repository (112). The information that is sent to the user
can, for example, be which AppOwner tried to access the credentials,
which AppInstance generated the request to access the credentials, which
AppIdentity entry was involved in the transaction, which service provider
is responsible for the AppInstance, what was the outcome of the attempt
to access the credential information, and so on. Based on this
information, the user (102) can revoke or modify the ActAs permissions if
different unauthorized attempts to access her credentials are being made.

[0058] Since the interoperability network (106) presents service providers
with a powerful set of tools in order to support dynamic routing through
the interoperability network (106), it is in practice unviable to analyze
the actual usage that the different services make of the users'
credentials. Therefore, the model presented above requires that the users
explicitly permission a provider to be able to use the users'
credentials, through the ActAs permissions, and thus the trust relations
between users and service providers remain in the users' control.

[0059] In one implementation, the users (102) can not only grant ActAs
permissions to various AppOwners, but also revoke permissions or assign
permissions that are based on policies. For example, a user (102) at
Company X can define a policy stating that under no circumstances should
his messages pass through an AppInstance hosted by his competitor,
Company Y. Another example of policy use is as follows: the user (102)
can require that whenever his credentials are used, the transmission of
his credentials be encrypted, or even that all transmissions within a
particular session be encrypted. Yet another example is that when the
credentials required for an application consist of an X.509 certificate,
the user can require that authentication within the session be
certificate authentication or better. Many other types of similar
examples can be constructed that fall within the general principles of
the invention as described herein.

[0060] One fundamental property of the interoperability network (106) that
enables the above-described functionality is the ability to store user
credentials (that is, the AppIdentities) in a central repository (112)
within the interoperability network (106). Another fundamental property
of the interoperability network (106) that enables the above-described
functionality is that the interoperability network (106) controls the
traffic flowing through the interoperability network (106) and has the
ability to bind permissions and policies to endpoints (114) within the
flow pattern of a message through the interoperability network (106). As
a result, a user (102) has complete control over which services can
access his credentials, and this access can be done automatically as soon
as the user (102) has identified himself to the interoperability network
(106) through a single sign on.

[0061] The invention can be implemented in digital electronic circuitry,
or in computer hardware, firmware, software, or in combinations of them.
Apparatus of the invention can be implemented in a computer program
product tangibly embodied in a machine-readable storage device for
execution by a programmable processor; and method steps of the invention
can be performed by a programmable processor executing a program of
instructions to perform functions of the invention by operating on input
data and generating output. The invention can be implemented
advantageously in one or more computer programs that are executable on a
programmable system including at least one programmable processor coupled
to receive data and instructions from, and to transmit data and
instructions to, a data storage system, at least one input device, and at
least one output device. Each computer program can be implemented in a
high-level procedural or object-oriented programming language, or in
assembly or machine language if desired; and in any case, the language
can be a compiled or interpreted language. Suitable processors include,
by way of example, both general and special purpose microprocessors.
Generally, a processor will receive instructions and data from a
read-only memory and/or a random access memory. Generally, a computer
will include one or more mass storage devices for storing data files;
such devices include magnetic disks, such as internal hard disks and
removable disks; magneto-optical disks; and optical disks. Storage
devices suitable for tangibly embodying computer program instructions and
data include all forms of non-volatile memory, including by way of
example semiconductor memory devices, such as EPROM, EEPROM, and flash
memory devices; magnetic disks such as internal hard disks and removable
disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing can
be supplemented by, or incorporated in, ASICs (application-specific
integrated circuits).

[0062] To provide for interaction with a user, the invention can be
implemented on a computer system having a display device such as a
monitor or LCD screen for displaying information to the user. The user
can provide input to the computer system through various input devices
such as a keyboard and a pointing device, such as a mouse, a trackball, a
microphone, a touch-sensitive display, a transducer card reader, a
magnetic or paper tape reader, a tablet, a stylus, a voice or handwriting
recognizes, or any other well-known input device such as, of course,
other computers. The computer system can be programmed to provide a
graphical user interface through which computer programs interact with
users.

[0063] Finally, the processor optionally can be coupled to a computer or
telecommunications network, for example, an Internet network, or an
intranet network, using a network connection, through which the processor
can receive information from the network, or might output information to
the network in the course of performing the above-described method steps.
Such information, which is often represented as a sequence of
instructions to be executed using the processor, can be received from and
outputted to the network, for example, in the form of a computer data
signal embodied in a carrier wave. The above-described devices and
materials will be familiar to those of skill in the computer hardware and
software arts.

[0064] It should be noted that the present invention employs various
computer-implemented operations involving data stored in computer
systems. These operations include, but are not limited to, those
requiring physical manipulation of physical quantities. Usually, though
not necessarily, these quantities take the form of electrical or magnetic
signals capable of being stored, transferred, combined, compared, and
otherwise manipulated. The operations described herein that form part of
the invention are useful machine operations. The manipulations performed
are often referred to in terms, such as, producing, identifying, running,
determining, comparing, executing, downloading, or detecting. It is
sometimes convenient, principally for reasons of common usage, to refer
to these electrical or magnetic signals as bits, values, elements,
variables, characters, data, or the like. It should remembered however,
that all of these and similar terms are to be associated with the
appropriate physical quantities and are merely convenient labels applied
to these quantities.

[0065] The present invention also relates to a device, system or apparatus
for performing the aforementioned operations. The system can be specially
constructed for the required purposes, or it can be a general-purpose
computer selectively activated or configured by a computer program stored
in the computer. The processes presented above are not inherently related
to any particular computer or other computing apparatus. In particular,
various general-purpose computers can be used with programs written in
accordance with the teachings herein, or, alternatively, it can be more
convenient to construct a more specialized computer system to perform the
required operations.

[0066] A number of implementations of the invention have been described.
Nevertheless, it will be understood that various modifications can be
made without departing from the spirit and scope of the invention. For
example, there can be organizational groupings of users (102) that share
the same AppIdentities. Also, the bindings to policy can be asserted by
the application definition, the AppOwner, or, for the case that the
AppIdentity is for a group of users, the administrator of that
AppIdentity. For example, for an organization that uses the same
certificate for all users to authenticate to a particular application,
the required policies are defined by the organization rather than the
individual users or in addition to the individual users.