User policy for trusting web sites7024691Abstract A system for trusting sites in a communication network, the communication network including a plurality of user nodes inter-linked through a proxy node to a site server. The system includes the proxy that is associated with an advanced policy being responsive to input certificates for verifying one or more declarations. Each one of the declarations is associated with a symbol. A user accessing from a user node, through a proxy node to a server site. The proxy node authenticating the site and then the server site providing to the proxy node, through said communication network, one or more credentials that refer to the site. The proxy node testing the credentials against the advanced policy in order to verify the declarations and displaying in respect of each verified declaration the corresponding symbol. Claims The invention claimed is: Description FIELD OF THE INVENTION
The invention further provides for a method for trusting sites in a communication network, comprising:
Still further, the invention provides for a system for trusting sites in a communication network, the communication network including a plurality of user nodes inter-linked through at least one proxy node to at least one site server, the system comprising:
Yet further, the invention provides for a system for trusting sites in a communication network, the communication network including a plurality of user nodes inter-linked through at least one proxy node to at least one site server, the system comprising:
BRIEF DESCRIPTION OF THE DRAWINGS In order to understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which: FIG. 1 is a generalized schematic illustration of a trusting site scenario according to the prior art; FIG. 2 is a generalized schematic illustration of a trusting site system according to a preferred embodiment of the invention; FIG. 3 is a generalized flow chart that corresponds to the trusting site system of FIG. 2; FIG. 4 illustrates an exemplary web page portrayed on the user node screen with symbols indicating trusted declarations of a given site in accordance with the trusting web sites technique of the invention; FIGS. 5-6 illustrate schematically an advanced policy utilized in accordance with one embodiment of the invention; and FIG. 7 illustrates schematically an exemplary application that utilizes an advanced policy in accordance with one embodiment of the invention. DETAILED DESCRIPTION OF THE INVENTION Turning now to FIG. 2, there is shown a generalized schematic illustration of a trusting site system according to a preferred embodiment of the invention. For convenience of explanation the description below focuses on internet based applications where the user node is running a browser. Those versed in the art will readily appreciate that the invention is, by no means, bound by this particular embodiment. Thus, by way of non-limiting example, in accordance with a modified embodiment the invention is applicable to Intranet applications; in accordance with another modified embodiment, instead of a browser that is incorporated in a user node a cellular telephone is used and by yet another modified embodiment a Personal Digital Assistance is used. Reverting to FIG. 2, there is shown a generalized schematic illustration of a system for trusting sites according to a preferred embodiment of the invention. By this embodiment the user defines a policy (204). There is further defined a trusted pane (205) (that is not controlled by site for which authorization is sought) in which the symbol(s) that correspond to the trusted declaration are displayed. The specified pane is combined with another pane where the original Web page (203) is displayed. If a given symbol appears in the trusted pane (e.g. a company name, say IBM, indicated schematically in FIG. 2 as triangle 206) the user can be sure that indeed the so displayed original page (in the other pane) originated from the specified company. In order to display the trusted symbols, the accessed web site (201) provides the web page that will be displayed along with the certificates which may either be at the site's disposal or which may alternatively be collected from other sources from remote certificate repository (e.g. certificates (211) collected from accrediting authorities (202)). The page and the certificates (212) are fed through proxy node (213) to the user node and the certificates are fed as an input to a policy module (204). By this particular example the policy module tests whether what the site declares to be, (i.e. a genuine IBM site), is indeed true and if in the affirmative the policy module would allow to display the symbol of IBM (206) on the trusted pane (205). Whereas in the example above the site is the one who "claims" (referred to also as "declares") about itself and provides the pertinent certificates, this is not necessarily always the case. Thus, in accordance with a modified embodiment the claim about the site is not originated by the site itself (e.g. the claim is originated by the user or the proxy and the claim will be verified using the policy) and accordingly the pertinent certificate(s) are collected by the policy. It is noted herein that the site for which authorization is sought has no control on the trusted pane. There follows herein an exemplary code which illustrate one possible variant how to realize the trusted pane.
where:
As shown, the proxy builds a page that consists on two distinct panes, the first (designated in the above example trustPane) is the trusted pane generated by the proxy (and in which the specified symbols will be displayed) and the second (designated in the above example requestedUrl) is the original page of the site. If desired, the two pane structure is maintained also in other pages that are displayed. Those versed in the art will readily appreciate that the two pane structure is only an example and the invention is not bound thereby and a fortiori not by the specific realization thereof. By one embodiment the policy is capable of testing two or more declarations and in respect of each one of them to display an appropriate symbol (in the case that the corresponding declaration is verified). As shown in FIG. 2, two additional symbols (207) and (208) are displayed (in the trusted pane) standing for "visa approve" and rated by "RSAC" declarations, respectively. The specified symbols are displayed for illustrative purposes in the form of rectangular and elliptic shapes. Whilst in the system of FIG. 2 the user policy (204) is associated with the user node (200) this is not necessarily always the case and by another preferred embodiment the specified policy module is associated e.g. with the proxy node (213). Turning now to FIG. 3, there is shown a generalized flow chart that corresponds to the trusting site system of FIG. 2 in accordance with one embodiment of the invention. As shown, browser (300) of the user node communicates with the proxy node (301) which, in turn, communicates with the so accessed web site (web server (302)). The proxy further communicates with policy server (304) which is capable of communicating with a certificate repository (305). In operation, the user requests a web page (311) and apply preliminary authentication sequence using e.g. the known per se SSL protocol. The request is captured by proxy node (301) which forwards it (312) to the web server (302). The web server supplies a site certificate during the SSL server authentication phase (313). Having received the certificate and the page to be displayed, the proxy (301) forwards the certificate to the policy server which tests the certificate by retrieving the identity of the subject (e.g. public key of the site) and tests the claims of the ID against the policy (and if needed collects more certificates from certificate repository 305) and verify what the site declares to be true. To this end, the policy server (304) employs a user policy, which may be pre-stored in the server, or alternatively fed as an input (314) (as is the case in the specific embodiment depicted in FIG. 3). Should the server require more certificates it would address certificates repository (305), e.g. according to a pre-defined configuration or the address indicated in the certificate that was provided by the web server during the SSL authentication phase. By the specific example of FIG. 3, the policy server includes role assignment module associated with role policy such that subjects (the subject signifies by this embodiment the site's identity are mapped to roles, according to the role policy, and the roles correspond to the declaration(s) of the site. Reverting now to FIG. 3, the server policy maps the subject (i.e. the site identity (302)) to a role or roles according to the policy and, if required, collects (315) more certificates from the certificate repository (305). The so mapped roles are delivered (316) from the policy server (304) as an input to the proxy (301) which then builds the trusted pane and sends it (317) along with the page to the browser (300). In the specific example under consideration, the roles (316) corresponds to the following verified declarations: 1) the site is a genuine IBM site, 2) the site is Visa approved; and 3) the site is rated by RSAC. Accordingly, the trusted pane will include the three symbols that correspond to these verified declarations. Those versed in the art will readily appreciate that the architecture of FIG. 3 is only optional and other variants may apply, all as required and appropriate. The resulting web page with the trusted pane that includes the specified symbols is illustrated for example in FIG. 4 where the IBM symbol (401), Visa symbol (402) and RSAC symbols (403) in the trusted pane (404) of web page (405). In the embodiment described in reference to FIG. 3 the SSL protocol was utilized and a rudimentary policy was employed based on (i) a single certificate that is provided by the web server or (ii) a certificate chain provided by the site (and/or by others, which the case may be). In other words, a certificate that normally does not qualify to map a subject to a given role will nevertheless enable to map the subject to the specified role if said certificate belongs to a certificate chain whose root certificate qualifies for mapping the subject to the specified role. The single certificate (if verified) can give rise to two declaration or more. It goes without saying that if only once certificate is used (which is the case of rudimentary policy), the step of collecting other certificates (using repository 305) is not applicable. As will be explained in greater detail below, the certificate collection step is sometimes required in the case that an advanced policy is employed. By a preferred embodiment the repertoire of declarations can be increased to support any declaration that a site wishes to claim about itself. By this embodiment appropriate symbol can be designed to any one of the specified declarations and displayed in the case that the respective declaration is verified. In accordance with another preferred embodiment of the invention an advanced policy is utilized. The advanced policy employs a role assignment module as disclosed in co-pending application # U.S. Ser. No. 09/298,991 filed on Apr. 26, 1999 assigned to Applicants which is incorporated herein by reference. An exemplary embodiments of the specified advanced policy are depicted in FIGS. 5 and 6 that correspond to FIGS. 5 and 6 respectively of the specified '991 application. In the description below with reference to FIG. 5 the terms role and group are used interchangeably. In accordance with this embodiment (with reference to FIG. 5), there is provided a general-purpose policy (410) that is defined by a role policy language. The role policy language is a flexible tool using role assignment primitives that are especially adapted for definition of role assignment policies. By using this language, role assignment policy may be defined for a desired application in a relatively simple manner without undue excessive programming effort, as would be the case, had a conventional programming language such as prolog been used. The so defined policy may be fed to a system of the kind depicted in FIG. 5, and would govern the operation of the role assignment module. Now, should a new (or an amended) policy be required, it is defined using the specified language and the so modified (or new) policy is fed to the role assignment module. The use of a language of the kind specified is advantageous, however not obligatory. A typical, yet not exclusive, example of using a role assignment module in accordance with the advanced policy is illustrated in FIG. 6. As shown, each role is represented as a group (501 to 504). As is known per se, the policy is operated only upon the authorization of a policy owner, who is normally the entity who provides access to the requested resource and in accordance with this invention the specified entity is the proxy. The policy owner holds a key which enables to operate the policy (by the specific embodiment of FIG. 6, the "self" block 500 represents the key of the policy owner). If desired, the policy owner may have additional privileges as will be explained in greater detail below. According to the policy of FIG. 6, each group has one or more rules on how to map subject or issuer of certificate to a role. A rule defines a certificate or certificates that are subject to operators and possibly function(s) on the attribute(s) of the certificate(s). A function may be NULL in which no constraint is posed on the certificate (or certificates) attributes. Attribute, in this context, is a statement about the subject in the certificate which statement is signed by the issuer of the certificate. For example, group 3 (503) has a rule which stipulates that a subject X can be mapped to the group if there exists a certificate (511) where X is the subject and whose issuer is in group 2 (502), and there exists a certificate (512) were X is the subject and whose issuer is in group 1 (501) such that the function F (520) holds. The function itself is expressed as constraints on the attributes in the certificates (511) and (512). By this particular example, the rule applies boolean AND operator to the certificates (511) and (512). The advanced role policy in accordance with this embodiment of the invention does not assume any knowledge about the issuers of the certificates, but only that they should belong to some group (or groups) in the policy. Thus, in order to map a subject to group (503), certificates 512 and 513 should exist, provided that the issuers belong to group 2 and group 3. There follows now a brief description on how to map an issuer to a role in accordance with an embodiment of advanced policy utilization. As is well known, typically (although not necessarily), an issuer issues a certificate by signing the certificate contents using his private key. Considering that the issuer's public key can be obtained from some public database, the identification of the issuer can be easily determined. Thus, by the specified embodiment, in order to map an issuer to a role, it is only required to check whether the public key thereof belongs to the specified role without requiring any further knowledge on the issuer and in particular avoiding the standard dependent DN testing. Those versed in the art will readily appreciate that the public key unique identifier is only an example, and by alternative embodiments other unique identifier(s) may be employed. Reverting now to the example of FIG. 6, if, for example, the policy can't reach a decision about X in group 3 (503) because, say, there exist certificates (511) and (512) that satisfy function (520), but the issuer Y of say, certificate (511) is not known to be in group 2 (502) (i.e. the public key thereof is not known to belong to group 2), then the policy tries to map Y to group 2, and if succeeds, then it can map X to group 3 (503). Y, in its turn, can be mapped to group 2 if it meets the rules that allow mapping a subject to a role, i.e. if Y can provide certificates (where Y is the subject of the certificates) that meet the provisions of the specified rules (for becoming a member in group 2). Seeing that Y's public key (standing for Y's unique identifier) is not known in group 2, the lists of certificates that facilitate the mapping of Y into group 2 are rendered Y's unique identifier. In order to provide the required certificates, a certificate collector may be used to collect missing certificates from remote repositories. The dynamic nature of the advanced policy in accordance with this embodiment is illustrated, for example, in a rule, which stipulates that a new issuer X can enter group 1 (501), if he is the subject of two certificates (513 and 514), whose respective issuers already belong to a group 1. The primitives of the policy language include by one embodiment, operators that one applied to one or more certificates and optionally functions applied to attributes of the certificates. Thus, the boolean AND/OR operators are applied to one or more certificates, and the operators exist or not exist are applied to one certificate. Functions are applied to attributes of certificates, and are selected from the group that includes: boolean AND, boolean OR (applied to two or more attributes) boolean NOT (applied to one attribute), greater than, equal, not equal, lower than, etc. Those versed in the art will readily appreciate that the specified primitives are only illustrated by way of example, and effectively any operations applied to certificates and or attributes are applicable. By utilizing the specified policy, a negative (NOT) rule may stipulate that X can be mapped to a group if there does not exist a certificate such that a given function F is satisfied. More specifically, in FIG. 5, a rule may prescribe for example that X will enter to group 3 (503) if there does not exist a certificate (511). Insofar as negative certificate is concerned, considering that it is difficult to prove that there does not exist a certificate, a possible practical solution would consider checking only the certificates that are stored in the local database of the role policy, whilst avoiding excessive processing in attempting to collect more certificates from other sources in order to prove the negative rule. By the particular example of FIG. 6, this would require checking only the certificates stored locally and accessible to the role assignment module. It should be noted that the term "subject" or issuer should be construed in a broad manner as encompassing amongst the other: individual user, a computer, an application, and organization etc. A more specific example is given with reference to FIG. 7 illustrating schematically an exemplary application that utilizes an advanced policy in accordance with one embodiment of the invention. As shown, if subject is mapped to Privacy-OK site (800) or to Kids-OK site (801) roles the symbol of RSAC (802) will be displayed in the trusted pane, and, likewise, if the subject is mapped to the Known Company role (803) the IBM symbol (804) is displayed in the trusted pane and, by the same token, mapping to Visa-OK Seller role (805) will lead to the display of the Visa symbol (806). The advanced nature of the policy is illustrated, for example, in connection with the Kids-OK site (801) role. Thus, if a subject (site) is not directly mapped to the Kids-OK site (801) role, then the specified subject can nevertheless be mapped to the specified role if the specified subject is in a certificate signed by an issuer that, in turn, is mapped to the Rating Agency role (807) (such certificate is provided by means of link 808), and provided that there is no negative certificate from the synagogue. Link (809) further illustrates the advanced nature of the specified policy. Thus, if a subject of a certificate is not directly mapped to the Rating Agency role (807) it can nevertheless be mapped to the specified role if this subject is signed by an issuer that in turn is mapped to the specified role (807). In the latter example known symbols are utilized (Visa, IBM etc.). If desired the symbols may not necessarily have a known form and accordingly one or more of them is configured to a desired form (e.g. by the proxy) to correspond to a given declaration or declarations. Utilization of the specified advanced policy may be applied not only to a repertoire of two or more declarations as described with reference to the previous embodiments, but also to a more degenerated form, e.g. a pre-defined and unconfigurable symbol form (such as the hitherto known key symbol) being indicative of a pre-defined declaration (i.e. complete key signifying "secured site"). Those versed in the art will readily appreciate that the policy module is not necessarily associated with the user node and, if desired, it is associated with the proxy node (as depicted for example in FIG. 3). Whilst the policy described above utilized role assignment module, those versed in the art will readily appreciate that the invention is by no means bound by the utilization of role-based policy. It will also be understood that the system according to the invention may be a suitably programmed computer. Likewise, the invention contemplates a computer program being readable by a computer for executing the method of the invention. The invention further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the method of the invention. In the method claims that follow, alphabetic characters or roman symbols used to designate claim steps are provided for convenience only and do not imply any particular order of performing the steps. The present invention has been described with a certain degree of particularity but those versed in the art will readily appreciate that various alterations and modifications may be carried out without departing from the scope of the following claims:
|
Same subclass Same class Consider this |
||||||||||||||||||||||||||||||||||||||||||||||||||