HK1174446B - Method and client device of trustworthy device claims for enterprise applications - Google Patents

Description

Method and client device for trusted device declaration for enterprise applications

Technical Field

The invention relates to the field of communication, in particular to a device declaration technology.

Background

Many organizations seek to provide users with the ability to transparently access applications from any location using any device at any time. Providing this level of access to the user involves overcoming a number of obstacles, including those related to security. For example, an organization may provide different levels of application access to users depending on the user's role in the organization and/or the user's relationship to the organization.

Disclosure of Invention

Commonly assigned U.S. patent application No. 12/822,724 entitled "network layer claiming based access control," filed 24/6/2010, discloses techniques for providing flexibility in making access control decisions at the network layer of the OSI stack through the use of information provided in the "claims" (also referred to as assertions by those skilled in the art). Briefly, the above-referenced application discloses that claims may provide information useful in making access control decisions at the network layer. In this regard, the statement may include information about any of the following: a number of attributes of the computer requesting access to the resource, circumstances surrounding the requested access, the resource requested to be accessed, and/or other information. In accordance with the disclosed techniques, information provided in a claim can be evaluated in view of one or more access control policies and used in deciding whether to grant or deny access to a particular network resource to a requesting computer. Since the information provided in the declaration may be more detailed than previously used to make access control decisions at the network layer, access control policies may be more flexibly formulated and greater flexibility may be provided in making access control decisions to take into account information having a transformed nature or type.

Applicants have recognized that information provided in a declaration describing the nature or attributes of a computer requesting access to an application program (hereinafter referred to as a "device declaration") can be used by the application being requested to access to derive any of a number of types of application functionality. The functionality may include access authorization and/or other security-related functionality, or any of a variety of other types of functionality. For example, an application may verify that a device satisfies certain criteria before making particular functionality or data available to the device, may generate an output that is appropriate for the characteristics and/or capabilities of the device, or use information provided by the device in a declarative form in any of a number of other ways. Embodiments of the present invention are not limited to any particular use.

Certain embodiments of the present invention provide a process whereby information in a device claim is converted into a form that an application is configured to process. In this regard, applicants have recognized that while device claims are conventionally used (e.g., to enable flexible decisions to be made regarding access control, as disclosed in the above-referenced commonly assigned applications), they are conventionally not used by applications, and applications are not configured to process device claims in the form in which they are conventionally provided. As a result, some embodiments of the invention allow information in a declaration to be provided to an application in a form that the application is configured to consume. For example, device claims are often issued by a Security Token Service (STS) in the form of an X.509 certificate, while applications are not configured to process device claims provided in this form. According to some embodiments of the invention, device claims included in an X.509 certificate may be converted into a form that an application is configured to process, such as a Security Assertion Markup Language (SAML) token. In some embodiments, the x.509 certificate may first be converted to a Kerberos ticket (e.g., as described in the above-referenced application), and then converted to a SAML token to be provided to the application. In other embodiments, the X.509 certificate may be converted directly to a SAML token without first being converted to a Kerberos ticket. Any of a variety of implementations are possible, and embodiments of the invention are not limited to providing device claims to an application in any particular form, or to converting device claims to that form in any particular manner.

In some embodiments, a device claim provided to an application is generated such that the device claim is "trusted" such that the application may be assured that the information represented therein is an accurate and true representation of device characteristics and/or attributes. For example, some embodiments of the invention provide certificates that include device claims to be generated via a remote attestation process in which a client device obtains an assessment of its state and characteristics from one or more data sources (e.g., external data sources) and provides the assessment to an attestation server in order to generate the device claims. Because device claims are generated via a remote attestation process, they may be accepted by an application as a trusted representation of the state, characteristics, and/or attributes of a device.

The foregoing is a non-limiting summary of the invention as defined by the appended claims.

Drawings

The drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:

FIG. 1 is a block diagram depicting a system in which a client device obtains a certificate that includes device claim information, in accordance with certain embodiments of the invention;

FIG. 2 is a block diagram depicting an example system including components for generating device claim information in a format suitable for consumption by a web application;

FIG. 3 is a block diagram depicting a system including components that may be used to convert a machine certificate to a SAML token, in accordance with certain embodiments of the present invention;

FIG. 4 is a flow diagram depicting an example process whereby a process security token service receives and processes device claim information from a client device, in accordance with certain embodiments of the invention;

FIG. 5 is a flow chart depicting an example process whereby a process client device obtains device claim information in a format suitable for consumption by an application;

FIG. 6 is a flow diagram depicting an example process whereby a process application may process device claim information received from a client device;

FIG. 7 is a block diagram depicting an example computer system upon which certain embodiments of the invention may be implemented; and

FIG. 8 is a block diagram depicting an example memory on which instructions embodying aspects of the invention may be stored.

Detailed Description

FIG. 1 depicts an example system that can be employed to generate a certificate that includes a trusted device claim. The system of FIG. 1 ensures the "trustworthiness" of device claims to ensure their authenticity and integrity to downstream entities, such as applications that receive the claims for processing. In the example system of fig. 1, trustworthiness is ensured via a remote attestation process whereby client device 110 authenticates itself to attestation server 142 (implemented on server 140 in the example shown) over one or more networks 130. Because the client manifests itself as trustworthy via a remote attestation process, attestation server 142 "attests" the device assertion to be a true, genuine, and trusted indication of the state, characteristics, and/or attributes of client device 110. The device claims designated as trusted may then be used with respect to requests to access network resources with client device 110, and the accessed resources may be assured that information describing the state, characteristics, and/or attributes of client device 110 is accurate.

In the example system shown in fig. 1, client device 110 contacts server 140 to request a certificate in the form of a claim that includes information about client device 110. For example, the request issued by client device 110 to server 140 may be for an X.509 certificate provided in a declarative form that includes information about client device 110. Of course, not all embodiments of the invention may include a device claim in an X.509 certificate, as any of a variety of forms may be employed, and embodiments of the invention are not limited to any particular implementation. Furthermore, device claims may be provided in any suitable form, as embodiments of the invention are not limited in this respect. For example, in some embodiments of the present invention, device claims are represented via one or more Issuance Policy (IP) OIDs, which one skilled in the art of security and authentication will recognize is a hierarchical digital construct encoded using x.509 extensions that may be used to convey device status and characteristics. Of course, embodiments of the invention are not limited to using IPOIDs to represent device claims, as any one or more suitable representations may alternatively be employed, including those encoded using proprietary techniques.

The device claims may include any of a number of types of information related to the client device 110. For example, the information may include an indication of the "health" of the client device 110 (e.g., whether the device is equipped with security and/or antivirus software, whether particular (e.g., security) software is activated, whether the client device employs a firewall, whether a firewall is operational, whether an antivirus signature is up-to-date, etc.), the type of cryptography the client device uses to access the resource (e.g., whether signature and/or encrypted communications are used for communications, the type of encryption, etc.), an identifier of the client device 110, the role the client device plays (e.g., as a desktop computer, database server, web server, etc.), the organizational relationship of the client device (e.g., operated by a sales department, operated by a financial department, etc.), its owner (e.g., company, employee, vendor, etc.), the geographic location of the device, the location of the client device, the type of the client device, and/or any of a variety of other types of information. Embodiments of the invention are not limited in this respect.

It should be appreciated that the client device 110 shown in FIG. 1 may be any suitable computing device, such as a desktop or laptop computer, a mobile phone, a personal digital assistant, a content rendering device, a television, a game console, and/or any other suitable type of device. Embodiments of the invention are not limited to use with any particular type of device.

To collect information about the client devices 110, the data collector 114 communicates with one or more data sources. In some embodiments, the data collector 114 is extensible such that the information it collects may be supplemented over time (e.g., via one or more plug-ins). Each data source provides information indicative of the status and/or health of the client device 110 based on the information supplied to the data source by the data collector 114. In certain embodiments, each data source may "sign" the information it provides to the data collector 114 to provide assurance of the accuracy of the information.

In the illustrated example, the data collector 114 communicates with a firewall Device State Provider (DSP)120 to provide information about the state of a firewall on the client device 110, communicates with a Security Health Agent (SHA)122 to provide information about the health of the client device 110, communicates with a geo-location DSP124 to provide information about the current physical location of the client device 110, and communicates with an anti-malware DSP126 to provide information about an anti-malware engine (not shown) on the client device 110. The information provided to any or all of the components 120, 122, 124, and 126 may, for example, describe the state of the client device 110 at or after any of a variety of events that occur during the life cycle of the client device 110, such as a reboot of its operating system (not shown in fig. 1), a resume from hibernation/sleep, installation of one or more drivers or software patches, initiation of a network connection, a change in location, or other events. The dynamically generated information and/or information may be context-dependent in that it may relate to the state of the client device at a particular time, the circumstances during which the claim was requested (e.g., the location of the device), and so forth.

In the illustrated example, the data collector 114 receives signed information from each of the data sources 120, 122, 124, and 126 and provides the information to the attestation client 112 on the client device 110. Of course, embodiments of the invention are not limited to such an implementation, as any of a variety of transforms may be applied to information received from any of data sources 120, 122, 124, and 126.

In addition, the attestation client 112 communicates with the TPM 116. TPM116 may perform any of several functions related to remote attestation processes. For example, the TPM116 may allow events to be collected in its Platform Configuration Registers (PCRs); allowing generation, storage and use of keys; allowing generation of a "quote" on a construct called a "TCG log" (not shown) to prove to a remote party the trustworthiness of an event reported in the log; maintaining a "boot counter" that can be used to distinguish between successive boot cycles and provide additional security across hibernation/restart events; and/or perform other functions. Information generated as a result of any one or more of these functions may be passed to attestation client 112. Of course, it is not necessary to employ a TPM in the remote attestation process, as embodiments of the invention are not limited in this respect. If the TPM provides the indication, the indication may be provided in the form of a measurement expressed in numerical form, although embodiments of the invention are not limited in this respect.

The attestation client 112 then provides the information gathered from the data sources 120, 122, 124, and 126 and the indication received from the TPM116 to the attestation server 142 via the network 130. In some embodiments, attestation server 142 may evaluate the information received from attestation client 112, such as by validating measurements generated by TPM116 to determine that the measurements have not been modified after generation, and/or by determining whether client device 110 is free of viruses. Of course, attestation server 142 may evaluate any information received from attestation client 112 in any of a variety of ways, as embodiments of the invention are not limited in this respect. If the evaluation results in that generation of a device claim should continue (as an example, if client device 110 is determined to be free of known malware, including but not limited to known viruses), attestation server 142 may initiate generation of a device claim for client device 110.

In some embodiments, initiating attestation server 142 to generate an assertion implicitly means that information received from the client device has been accepted as trustworthy by attestation server 142, and thus device assertions generated by the attestation server based on information accepted from client device 110 are also accepted as trustworthy by other (e.g., downstream) entities.

To initiate the generation of a device claim, attestation server 142 issues a request to a claim engine 144 residing on server 140. In the illustrated example, claims engine 144 queries active directory 150 to retrieve information about client device 110 and/or its user (if performing compound authentication, as described below).

Claims engine 144 then evaluates the information received from the sources described above, including attestation server 142 and active directory 150, and determines which device claims should be generated relating to client device 110. In some embodiments, this determination is driven at least in part by one or more policies implemented by claims engine 144, claims engine 144 managing which device claims should be generated based on the received information. For example, the policy may take into account an indication that proves the trust that server 142 has with the information, which may be generated using any suitable technique. Of course, embodiments of the invention are not limited to such implementations, as one or more policies need not be used to control assertion generation, and if one or more policies are employed, they need not account for an indication of trust.

The indication of device claims that should be generated is then passed by claims engine 144 to claims generator 146. In the example of fig. 1, claims generator 146 includes the device claims in an x.509 certificate, although embodiments of the invention (as described above) are not limited to such an implementation. The device claims may be included in any suitable data structure or structures in any suitable form or forms. If an X.509 certificate is employed, claims generator 146 may provide the certificate including the device claim to attestation client 112 via attestation server 142 and network 130.

FIG. 2 depicts an example system in which device claims included in a certificate (e.g., generated by the example system shown in FIG. 1) are converted into a form suitable for processing by a web application 270. Specifically, in the example system of FIG. 2, the device claims in the certificate are first included in a Kerberos ticket, which is then converted into a SAML token, which is a form that conventional applications are configured to process. The client device 110 may employ a SAML token in connection with an attempt to access the web application 270. For example, in some embodiments, the client device 110 executes a browser application to initiate access to the web application 270, and the browser may employ a SAML token in connection with the access attempt. However, embodiments of the invention are not limited to such implementations, as any suitable application, browser, or other may use information provided in any suitable form in connection with an access attempt. It should also be appreciated that while the example system illustrated in FIG. 2 depicts a web application that client device 110 is attempting to access, embodiments of the invention are not limited to such an implementation, but may provide access to any application, service, object, or other component that is accessible via any one or more communication protocols, which may or may not include the hypertext transfer protocol (HTTP). Embodiments of the invention are not limited in this respect.

In the illustrated example, client device 110 first obtains a certificate including a device claim from attestation server 140, such as in the manner described above with reference to fig. 1. Fig. 2 symbolically represents this process as an interaction between the client device 110 and the attestation server 140, indicated via arrows 205 and 210.

In the illustrated example, upon providing the client device 110 with the certificate including the device claim, the client device 110 issues a request to an active directory/key distribution center (AD/KDC)255 to generate a Kerberos ticket including the device claim, as indicated by arrow 215. The generation of the Kerberos ticket may be performed in any of a variety of ways, as embodiments of the invention are not limited in this respect. One example technique is disclosed in the above-referenced U.S. patent application No. 12/822,724, where AD/KDC255 provides a Ticket Granting Ticket (TGT) to client device 110, and client device 110 uses the TGT to request a ticket granting service (not shown in fig. 2) to issue a Kerberos ticket including a device claim, although embodiments of the invention are not limited to such an implementation. In the illustrated example, the client device 110 is provided with a Kerberos ticket embedded with a device claim, as indicated via arrow 220.

In some embodiments, a composite authentication may be performed (e.g., for both the client device 110 and its user). For example, a request issued by client device 110 to AD/KDC255 may be for a TGT that includes not only a device claim but also a user claim. In such an implementation, AD/KDC255 may retrieve information about the user and include this information or a derivation thereof as a user claim along with the device claim in the TGT provided to client device 110.

It should be appreciated that the above-described interactions between client device 110, attestation server 140, and AD/KDC255 may be performed at any time and need not be directly in response to an attempt by client device 110 to access web application 270. For example, the client device may interact with attestation server 140 and AD/KDC255 before attempting to access web application 270, such that the client device has a TGT with an embedded device claim (and/or user claim (if compound authentication is performed)) when access to web application 270 is desired. Embodiments of the invention are not limited to obtaining a Kerberos ticket at any particular time or in response to any particular event, as any suitable implementation may be employed.

In the illustrated example, when client device 110 attempts to access web application 270, web application 270 redirects client device 110 to Security Token Service (STS) 265. This may be accomplished in any of a variety of ways, as embodiments of the invention are not limited to any particular technique. In the illustrated example, the web application 270 has a trust relationship with the STS 265. Such a connection or relationship between a web application 270 and an STS265 may be formed or indicated using any suitable approach, as embodiments of the invention are not limited in this respect. For example, a provider of the web app 270 may make the STS265 specifically available for receiving redirected requests from client devices seeking access to the web app 270, the STS265 may be a separate service established for this purpose, or the STS265 may form part of any other suitable arrangement. Any of a variety of implementations are possible, and embodiments of the invention are not limited in this respect.

In the illustrated example, STS265 then redirects client device 110 to STS260, STS260 residing on the same side of organization boundary 202 as client device 110 and having a trust relationship with STS 265. As with the trust relationship between web application 270 and STS265, any suitable technique can be used to form or indicate a trust relationship between STS265 and STS 260. For example, a trust relationship between STS265 and STS260 may have been established prior to an attempt by client device 110 to access a web application, and STS260 may be made available specifically for handling redirected requests from client devices to access a web application. Any of a variety of implementations are possible.

In the illustrated example, when STS260 receives the redirected access request, it instructs client device 110 to request a Kerberos ticket from the ticket granting service to access STS 260. After obtaining the Kerberos ticket, the Kerberos ticket is provided to STS260, and STS260 extracts the device claims and transforms the device claims into claims in SAML tokens. In some embodiments, the device claim is included in the SAML token by transforming information from the Kerberos ticket into the SAML token. However, any of a variety of transformations or derivation of the information provided in the Kerberos ticket is possible and may be performed, as embodiments of the invention are not limited in this respect.

In some embodiments, STS260 may include a user claim as well as a device claim in the newly generated SAML token. If a user claim is to be included, STS260 can verify the user-supplied information (e.g., via form-based authentication), indicated via dashed arrow 228, with AD/KDC 255. For example, the user-supplied information may be verified using information retrieved from the active directory server, and if verifiable, the user-supplied information may be included as a user claim in the SAML token.

Once the SAML token is generated, STS260 signs the token and returns it to client device 110 and then redirects client device 110 to STS 265. Client device 110 provides the newly generated SAML token to STS 265. Because STS260 generated the SAML token and there is a trust relationship between STS260 and STS265, STS265 then generates and signs and issues the SAML token to client device 110. Given the trust relationship between the STS265 and the web application 270, the web application 270 grants access to the client device 110 when the client device gives a SAML token issued by the STS265, as indicated via arrow 235.

The Web application 270 may use the device claims included in the SAML token in any of a variety of ways. For example, the web application 270 may use information provided in the device claims to verify that certain security measures are in place on the client device 110 before granting access to certain types of data. In this regard, certain organizations conventionally require client devices to have bitlockers, which are cryptographic components that prevent unauthorized access to data in the event that the device is compromised and activated to access certain (e.g., high business impact) data. Web application 270 may employ information in the device assertion included in the SAML token to determine whether client device 110 has activated BitLocker before granting access to certain data and/or certain application functions.

In another example, the web application 270 may use information in the device claims to verify that no known malware is executing on the client device 110 before granting access to certain data. For example, the web application 270 may use the information in the device claims included in the SAML token to verify that no known malware is resident on the client device 110 prior to providing access to certain data and/or application functions.

The information in the device claims may also be used by security-independent application functions. For example, information in a device claim may indicate characteristics or capabilities of the device, and this information may be used by the web application 270 to tailor output to those characteristics or capabilities. For example, if the client device 110 is a mobile phone with a certain CPU, amount of memory, screen resolution, etc., a device claim indicating these characteristics may be included in the SAML token provided to the web application 270, and the web application 270 may use this information to generate and/or modify content appropriate for the characteristics of the device.

It should be appreciated that the examples given above represent only a few of the many possible ways in which an application can process information provided in a device claim. Embodiments of the invention are not limited to using this information in any particular manner.

It should also be appreciated that while FIG. 2 depicts the generation of a SAML token including device claims from a Kerberos ticket, not all embodiments of the invention are limited to such an implementation. For example, the SAML token may instead be generated directly from the certificate, without performing an intermediate step of generating a Kerberos ticket. FIG. 3 depicts an example system that generates a SAML token including device claim information from a machine certificate received from a certification server without first converting the certificate to a Kerberos ticket.

In the example shown in fig. 3, client device 110 first obtains a certificate including a device claim from attestation server 140, which may be performed in substantially the same manner as described above with reference to fig. 1. Fig. 3 symbolically represents this process as an interaction between the client device 110 and the attestation server 140, indicated via arrows 305 and 310.

Once client device 110 receives the certificate including the device claims, it provides the certificate to STS agent 345, as indicated via arrow 315. If composite (i.e., user and device) authentication is desired, STS agent 345 may require the user of client device 110 (not shown in FIG. 3) to authenticate, such as via form-based authentication (FBA). If the user and device authentication is successful, STS agent 345 provides the credentials to STS350, as indicated via arrow 320. The STS350 then validates the user information by querying the active directory 355, as indicated via the dashed arrow 325. The STS350 then generates a SAML token that includes the authenticated user information received from the active directory 355 and the device information provided in the credentials. As with the process described above with reference to fig. 2, the device claim may be included in the SAML token by transmitting information from the credential to the SAML token or by applying any of a variety of transformations to the information included in the credential. Embodiments of the invention are not limited in this respect.

STS350 then provides the SAML token to STS agent 345 as indicated via arrow 330, and STS agent 345 then provides the SAML token to client 110 as indicated via arrow 335. The client device 110 then provides the SAML token to the web application 365 in a request to access the application. The client device 110 then uses the SAML token in conjunction with the access attempt, as indicated via arrow 340.

It should be appreciated that STS agent 345 is provided because, in the illustrated arrangement, flexibility is provided for client devices outside of organizational boundary 302. For example, if the client device 110 is within the organizational boundary 302, a Kerberos ticket may be employed instead.

It should also be appreciated that the techniques described above with reference to fig. 2 and 3 are merely exemplary, and that embodiments of the present invention may not include creating a SAML token for use in accessing a web application. For example, certain embodiments of the present invention may provide for the generation of a Kerberos ticket that includes device claim information and provide the ticket to a web application without first converting it to a SAML token. Other embodiments may require that the certificate including the device claim be provided to the application without conversion to a SAML token or any conversion otherwise performed. Embodiments of the invention are not limited to any particular implementation.

Fig. 4-6 depict example processes performed by the components depicted in fig. 1-3. Specifically, FIG. 4 depicts an example process whereby a process STS receives device claim information from a client device and processes the device claim information, FIG. 5 depicts an example process whereby a process client device provides device claim information to the STS and receives the information in a form suitable for consumption by an application, and FIG. 6 depicts an example process whereby a process application receives and processes device claims.

Referring first to FIG. 4, at the start of the illustrated example process, the STS receives device claim information from the client device in act 410. In act 420, the device claim information is transformed to be included in the output in a format suitable for processing by the application. For example, the device claim information may be included in a SAML token, Kerberos ticket, and/or other format or formats suitable for processing by the application. In act 430, the converted output is provided to the client device. The example process of FIG. 4 is then complete.

At the beginning of the example process shown in FIG. 5, the client device provides device declaration information to the STS in act 510. In act 520, device claim information is then received from the STS in a format suitable for processing by the application. In act 530, the device claim information is then provided to the application. The example process of FIG. 5 is then complete.

At the beginning of the example process shown in FIG. 6, in act 610, the application receives device claim information from the client device, the device claim information being provided in a format that the application is configured to process. The application then processes the device claim information in act 620. Processing may include, for example, performing functions that depend on the attributes of the client device described by the device claims. The example process of FIG. 6 is then complete.

Various aspects of the systems and methods for implementing features of the present invention may be implemented on one or more computer systems, such as the exemplary computer system 700 shown in FIG. 7. The computer system 700 includes an input device 702, an output device 701, a processor 703, a memory system 704, and storage 706, all coupled directly or indirectly via an interconnection mechanism 705 that may include one or more buses, switches, networks, and/or any other suitable interconnections. The input device 702 receives input from a user or machine (e.g., a human operator), and the output device 701 displays or transmits information to the user or machine (e.g., a liquid crystal display). The input and output devices are primarily useful for presenting user interfaces. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that may be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer may receive input information through speech recognition or in other audible format.

The processor 703 typically executes a computer program called an operating system (e.g., the microsoft Windows family of operating systems or any other suitable operating system) that controls the execution of other computer programs and provides scheduling, input/output and other device control, accounting, assembly, storage arrangement, data management, memory management, communication, and data flow control. In general, a processor and an operating system are defined as the computer platform for which application programs and other computer programming languages are written.

The processor 703 may also execute one or more computer programs to implement various functions. These computer programming languages may be written in any type of computer programming language, including a procedural programming language, an object oriented programming language, a macro language, or a combination thereof. These computer programs may be stored in the storage system 706. The storage system 706 may hold information on volatile or non-volatile media, and may be fixed or removable. The storage system 706 is shown in more detail in FIG. 8.

The storage system 706 may include a tangible computer-readable and writable nonvolatile recording medium 801 on which signals defining a computer program or information to be used by the program are stored. The recording medium may be, for example, a disk memory, a flash memory, and/or any other article of manufacture that may be used to record and store information. Generally, in operation, the processor 703 causes data to be read from the non-volatile recording medium 801 into volatile memory 802 (e.g., random access memory, or RAM) that allows the processor 703 faster access to information than does the medium 801. As shown in fig. 4, the memory 802 may be located in the storage system 706 or in the memory system 704. The processor 703 generally processes the data within the integrated circuit memory 704, 802 and then copies the data to the medium 801 after the processing is complete. Various mechanisms are known for managing data movement between the medium 801 and the integrated circuit memory elements 704, 802, and the present invention is not limited to any mechanism now known or later developed. The invention is also not limited to a particular memory system 704 or storage system 706.

Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.

The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, embodiments may be implemented using hardware, software, or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers and/or systems. Although a processor may be implemented using circuitry in any suitable form, such a processor may be implemented as an integrated circuit having one or more processors in an integrated circuit component.

It should be appreciated that any component or collection of components that perform the functions described herein can generally be considered one or more controllers that control the above-described functions. The one or more controllers can be implemented in numerous ways, such as with dedicated hardware, or by employing one or more processors that are programmed using microcode or software to perform the functions recited above. Where the controller stores or provides data for system operation, such data may be stored in a central repository, in multiple repositories, or a combination thereof.

It should be appreciated that a computer may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, or a tablet computer. Further, a computer may be embodied in a device not generally regarded as a computer but with suitable processing capabilities, including a Personal Digital Assistant (PDA), a smart phone, or any other suitable portable or fixed electronic device.

Also, a computer may have one or more input and output devices. These devices are primarily useful for presenting user interfaces. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that may be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer may receive input information through speech recognition or in other audible format.

The computers may be interconnected by one or more networks in any suitable form, including as a local area network or a wide area network, such as an enterprise network or the Internet. These networks may be based on any suitable technology and may operate according to any suitable protocol, and may include wireless networks, wired networks, or fiber optic networks.

Further, the various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Further, such software may be written using any of a number of suitable programming languages and/or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.

In this regard, the invention may be embodied as a computer readable medium (or multiple computer readable media) (e.g., a computer memory, one or more floppy disks, Compact Disks (CDs), optical disks, Digital Video Disks (DVDs), magnetic tapes, flash memories, circuit configurations in field programmable gate arrays or other semiconductor devices, or other non-transitory, tangible computer readable storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The computer-readable medium or media may be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above. As used herein, the term "non-transitory computer readable storage medium" encompasses only computer readable media that can be considered an article of manufacture (i.e., an article of manufacture) or a machine.

The terms "program" or "software" are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. In addition, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that when executed perform methods of the present invention need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.

Computer-executable instructions may take various forms, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

Moreover, the data structures may be stored on a computer-readable medium in any suitable form. For simplicity of illustration, the data structure may be shown with fields that are related by location in the data structure. These relationships may likewise be obtained by allocating storage for the fields to locations in a computer-readable medium that convey relationships between the fields. However, any suitable mechanism may be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags, or other mechanisms that establish a relationship between data elements.

Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.

Also, the invention may be embodied as a method, examples of which have been provided. The actions performed as part of the method may be ordered in any suitable way. Thus, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts concurrently, even though shown as sequential acts in illustrative embodiments described herein.

Use of ordinal terms such as "first," "second," "third," etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of "including," "comprising," or "having," "containing," "involving," and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

Claims (10)

1. A method for trusted device claims, comprising:

(A) receiving, at a computing device, one or more transformed device claims by an application (270) from a client device (110) via at least one network (130), each transformed device claim comprising a device claim, each device claim comprising attributes of the client device and being used to authenticate the client device to the computing device, the device claims being unrecognized by the application, a transformed device claim being recognized by the application;

(B) processing the one or more transformed device claims with at least one processor (703), the processing allowing execution of functionality of the application that depends on properties of the client device described by each of the one or more transformed device claims.

2. The method of claim 1, wherein each converted device declaration received in (a) describes attributes of the client device selected from a group of attributes consisting of:

whether the client device is equipped with security software,

whether the client device employs a firewall or not,

whether a firewall employed by the client device is operational,

whether the anti-virus signature on the client device is up-to-date,

the role played by the client device is,

the organization to which the client device is attached,

an owner of the client device, an

A geographic location of the device.

3. The method of claim 1, wherein (B) comprises performing a security-related function.

4. The method of claim 1, wherein (B) comprises generating an output tailored to the properties of the client device described by the one or more transformed device claims.

5. A method for trusted device claims, comprising:

(A) receiving, from a client device (110) via at least one network (130), one or more device claims that each describe an attribute of the client device and are used to authenticate the client device, each device claim being unrecognized by an application;

(B) generating a data structure comprising the one or more device claims, the data structure having a format suitable for processing by an application; and

(C) providing the data structure to the client device for use in connection with a request by the client device to access the application.

6. The method of claim 5, wherein (A) comprises receiving a certificate comprising the one or more device claims that each describe an attribute of the client device.

7. The method of claim 5, wherein (B) comprises generating a SAML token that includes the one or more device claims.

8. A client device (110) comprising at least one processor (703) programmed to:

requesting a certificate comprising one or more trusted device claims from a certifying authority accessible to the client device via at least one network, each trusted device claim describing properties of the client device, each trusted device claim being used to authenticate the client device and not recognized by a web application;

providing the certificate or a Kerberos ticket generated using the certificate to a Security Token Service (STS), the certificate or Kerberos ticket including the one or more trusted device claims;

receiving a Security Assertion Markup Language (SAML) token including the one or more trusted device claims from the STS; and

using a SAML token including the one or more trusted device claims in conjunction with a request to access the web application.

9. The client device of claim 8, further comprising a web-enabled component, and the at least one processor is programmed to enable the web-enabled component to use the SAML token in conjunction with a request to access the web application.

10. The client device of claim 9, wherein the web-enabled component comprises a browser application.