Authentication of services on a partition

Many systems (eg, blade servers or cellular services) utilize partitions that divide the system into separate sections to allow multiple operating systems to operate within the system. Partitions include two main categories, soft partitions and hard partitions. Hard partitions are implemented at the board level by dividing the system into physically separate partitions, which logically and electrically isolate multiple operating systems. Soft partitions are implemented at the processing core level by allocating server resources (eg, CPU and memory usage) to each partition, which functionally separates multiple operating systems but does not electrically isolate them. ..

The partition may have various services running within the partition. In order for a service to work within a partition, it may be necessary to request information and / or configuration changes from other partitions of the system. In the past, such requests have been executed without controlling access to the security domain or logging the request. However, increased awareness of system security has required authentication of the service before authorizing the execution of the request and / or logging the trail entry.

Embodiments of the present disclosure relate to systems and methods of authenticating services operating on a partition.

Briefly, one embodiment includes, among other things, a system for authenticating services. The system includes a partition configured to run services, a list of authentication services associated with the partition, and a management processor in communication with the partition, which puts the management processor in the list of authentication services. If listed, configure it to generate credentials for that service.

Another embodiment comprises, in particular, a method of authenticating a service running on a partition. This method initiates a request for credentials by a service, verifies that the service is listed in the authentication services group associated with the partition, and if the service is listed in the authentication services group, the credentials. It is provided to send the requested request to the management processor.

In another embodiment, it comprises, in particular, a computer-readable storage medium comprising a program that authenticates the service. When the computer processor executes the program, the program initiates a request to the processor for credential by the service, and the request contains a step containing a unique service identifier corresponding to the service, and is the service listed in the authentication services group? And if the service is listed in the authentication services group, send a request for credential to the management processor.

Other systems, methods, features, and effects relating to this disclosure will be apparent to those skilled in the art upon review of the drawings and detailed description below. All such additional systems, methods, features, and effects are included herein, within the scope of the invention, and are protected by the accompanying claims.

Many aspects of the invention will be further understood by reference to the drawings below. The components of the drawings are not necessarily on an exact scale and are emphasized in clarifying the principles of the invention. Further, in the drawings, the same reference number refers to the corresponding parts through a plurality of drawings.<figref num="1">It is a figure of the partition division system by one Embodiment of this disclosure.</figref><figref num="2">FIG. 5 is a diagram of the partitioned system of FIG. 1 after installing the management tools included in the exemplary authentication system according to one embodiment of the present disclosure.</figref><figref num="3">It is a figure of the authentication system of FIG. 2 at the time of service start by one Embodiment of this disclosure.</figref><figref num="4">FIG. 2 is a diagram of an authentication system of FIG. 2 including a service that requests a resource of a management processor according to an embodiment of the present disclosure.</figref><figref num="5">It is a flowchart explaining an exemplary method of authenticating a service running on a partition by one Embodiment of this disclosure.</figref>

Disclosed herein are various embodiments of methods and systems relating to the authentication of services running on a partition. Next, the description of the embodiment shown in the drawings will be described in detail, but the same reference number refers to the same part through a plurality of drawings.

When creating a partition in the system, the system's management processor (MP) instructs the processor-dependent hardware controller (PDHC) to bring up one or more interfaces associated with the partition to be configured. FIG. 1 is a diagram of a partitioned system 100 according to one embodiment of the present disclosure. The partitioned system may include as many partitions as desired. In the non-limiting embodiment of FIG. 1, a single partition 101 is shown for explanatory purposes only. Partition 101 communicates with PDHC106 via interface 109. The PDHC106 includes an in-band communication channel 107 associated with partition 101 and a block transfer (BT) interface 108, which communicate with the Common Information Model Object Manager (CIMOM) 111 and the Baseboard Management Controller (BMC) 112, respectively. Includes CIMOM111 and BMC112 in MP110. The partition management account 113 that manages partition 101 is also in communication with CIMOM111.

FIG. 2 is a diagram of the partitioned system of FIG. 1 after installing the management tools included in the exemplary authentication system 200. The management tool may be installed on partition 101 at the same time as or after the creation of partition 101. For example, in an HPUX environment, the software for Authentication System 200 may be installed with the operating system (OS). In Windows®, OpenVNS, Linux or other environments, the installation of the appropriate embodiment of the authentication system 200 may be done separately from installing the OS on the partition. Any OS may support updates and installation of additional services. Installation and update in any environment involves management or root access to partitions. A particular OS installed on partition 101 may use its OS-specific file system permissions to control access to interface 109.

In the embodiment of FIG. 2, the management tool installed on partition 101 includes an in-band communication daemon 202, an authentication daemon 203 for in-band communication, a message queue 204, and an authentication service (AuthServ) group 205. The in-band communication daemon 202 communicates with the in-band communication channel 107 via the interface 109. The in-band communication authentication daemon 203 communicates with the AuthServ group 205 via the message queue 204, and communicates with the block transfer interface 108 via the interface 109. AuthServ group 205 contains a list of service identifiers (SIDs). Associate a unique SID with the service running on the partition. In the non-limiting embodiment of FIG. 2, SID1 and SID2 are shown for explanatory purposes only. The number of SIDs associated with AuthServ Group 205 may vary in other embodiments. The list of SIDs in the AuthServ group 205 is additionally input by the partition management account 113, and the listed SID corresponds to the service that authorizes the operation on the partition 101. Such services include, but are not limited to, software applications such as, for example, payroll applications, global workload managers, or value-added applications.

In the embodiment of the in-band communication daemon 202, a request for an arithmetic resource for MP resources may be transmitted from a service running on partition 101 to MP110. In some embodiments, the in-band communication daemon 202 is prohibited from initiating a request between partition 101 and MP110. For example, daemon 202 may only forward requests between services on partition 101 and MP110. Therefore, in such an embodiment, the in-band communication daemon 202 does not need to have its own access credentials to access the MP110.

An embodiment of the authentication daemon for in-band communication 203 may be used to request credentials for a service from MP110 via interface 109 and BT interface 108. Interface 109 embodiments may include Intelligent Platform Management Interface (IPMI), which requires administrative user level access to connect to IPMI. In such an embodiment, the authentication daemon 203 may use a specially defined IPMI request to transmit data to the MP110. The authentication daemon 203 may also use the message queue 204 to communicate with the service.

The embodiment of AuthServ group 205 may be used to control access to message queue 204. Message queue 204 is used by the authentication daemon for in-band communication 203 to request credentials from MP110. Administrator-level access to partition 101 may be required to create, add, modify, or delete SIDs from AuthServ Group 205. Further, in the AuthServ group 205, the level of access to the resource of MP110 may be specified at the level at which a specific service is authenticated.

FIG. 3 is a diagram of the authentication system of FIG. 2 at the start of the service according to the first embodiment of the present disclosure. A single service 314 is shown in Figure 3, but any suitable number of services may also run on partition 101. Service 314 runs under a unique service authentication (SID) on partition 101. The service authenticated by partition management account 113 has the SID listed in AuthServ group 205. At startup, service 314 does not have to have credentials to access MP110. Therefore, the service 314 sends a request for credentials to the authentication daemon for in-band communication 203 via the message queue 204. Message queue 204 determines the validity of the request based on the SIDs listed in AuthServ group 205. Only services with the SIDs listed in AuthServ Group 205 can access the MP110 and make a request for credentials. In addition, the message queue 204 can execute the permission of the file system defined in the AuthServ group 205.

Upon receiving the request for credentials, MP110 checks to see if there is a credential for service 314 on partition 101. If the credential exists, the MP110 returns the credential to the in-band communication authentication daemon 203 via interface 109. The in-band communication authentication daemon 203 then returns the credentials to service 314. If the credential does not exist at that time, the MP110 creates a credential with a specially defined role for the requesting service 314. Its special role may be defined in the AuthServ group 205 by the partition management account 113 and the access rights to the MP110 may be tailored specifically for service 314. Therefore, the administrator may limit the access by the service 314 to only the necessary privileges as appropriate.

In one exemplary embodiment, in particular, the credentials may include a random and unique password issued by MP110 for service 314. In some embodiments, the password may be associated with, for example, the SID of the service, or a unique account created by the MP110 for the service 314. If the MP110 creates an account for the requested service, the account name may be returned to the service with a password, or the service 314 may use the SID as its account name. In other embodiments, the password may be adapted to the password length requirements to be configured, or may consist of both uppercase and lowercase letters and numbers, if the administrator so desires. Further, depending on the embodiment, there may be a minimum password length (for example, 8 characters or more).

In another embodiment of FIG. 3 involving multiple partitions, individual instances of the service may run on different partitions. Each individual instance of the service may require a unique credential for the service's home partition. The request source partition may be identified against the MP110 as part of the authentication and authentication process to ensure that the requesting service is authenticated and run on the request source partition. .. If the SID does not exist for the requesting service, MP110 may generate it for the service requesting a unique credential and use that credential to authenticate the request for MP110 resources from the requesting service. ..

FIG. 4 is a diagram of the authentication system of FIG. 2 including service 414 requesting MP resources according to one embodiment of the present disclosure. Referring to FIG. 4, if service 414 obtains credentials from MP110 via in-band communication authentication daemon 203, service 414 communicates with MP110 via in-band communication daemon 202 and interface 109 on in-band communication channel 107. You will be ready to do it. In-band communication channel 107 or daemon 202 embodiments may support basic HTTP authentication. When service 414 initiates a request to MP110, service 414 provides credentials, including, for example, the SID and / or other credentials from MP110, in the authentication field of the HTTP header of the request in accordance with HTTP Basic Authentication provisions. You may set it to. The credentials in the authentication field may be used to authenticate service 414, check the permissions defined for the service role in partition management account 113, and then make the request by MP110. In an embodiment of the authentication system, any suitable method of passing the credentials of service 414 requesting computing resources from the MP110 and authenticating may be used.

FIG. 5 is a flowchart illustrating an exemplary method 500 for authenticating a service running on a partition according to one embodiment of the present disclosure. Block 510 installs the service on the partition. At that point, assign the service to a unique SID. Depending on the embodiment, a unique service ID may be assigned by the administrator. In block 520, the unique SID of the service is added to the AuthServs on the partition by the entity that has root access to the partition. In other embodiments, the SID may be added by the administrator. At block 530, the service is started. At block 540, the service connects to the authentication daemon, makes a request to the MP for credentials, and sends the request via a message queue. In block 550, the message queue checks the SIDs listed in the AuthServ group to see if the requested service is listed. At block 560, when a service is listed in the AuthServ group, Message Queuing sends a request for credentials to the management processor over the interface, and at block 570, the management processor sends to the service on that partition. Create a specific credential. The management processor then returns these credentials to the service through the interface at block 580. The service continues to run in block 590, and the service uses the credentials issued in block 570 to make all requests to the management processor. The management processor may uniquely identify and authenticate services on a particular partition and, in some embodiments, log resource requests for services.

In some embodiments, in particular, the expiration date of the credential may be allowed. In such an embodiment, if the service does not resume for longer than the specified longest credential lifetime, the credential of the service expires. In one embodiment, the administrator may specify, in particular, the longest credential duration. In other embodiments, the longest credential duration may be a predetermined value. If the credential expires, the service's request to the management processor fails. If the failure is due to an expired credential, reconnect the service to the authentication daemon and request the updated credential. As long as the service is listed in the AuthServ group, the new credential request will succeed and the service will automatically receive the newly updated credential without further user or administrator intervention.

The embodiments of the present disclosure can be implemented in hardware, software, firmware, or a combination thereof. In various embodiments, the components of the system are implemented in software or firmware that is stored in memory and executed by an appropriate instruction execution system. In some embodiments, when implemented in hardware, the components of the system can be implemented in any or a combination of the following technologies well known in the art, which are logic gates that implement logic functions in data signals. These include individual logic circuits with logic gates, application specific integrated circuits (ASICs) with appropriate combinations of logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), and the like.

A software component may include an ordered list of executable instructions for implementing a logical function, from an instruction execution system, device or device, such as a computer-based system, processor-containing system, or from an instruction execution system, device or device. It can be embodied by other systems capable of fetching and executing instructions, or on any computer-readable medium used in connection with such systems. Further, the scope of the present disclosure includes embodying the functions of one or more embodiments with logic embodied in a medium composed of hardware or software.

A description or block of a process in a flow chart should be understood as representing a module, segment or part of code that contains one or more executable instructions that implement a particular logical function or step in that process. As will be understood by those who are somewhat proficient in the art of the present disclosure, the functions of the embodiment are performed in an order that is different from the order of the functions shown or described, substantially simultaneously or in reverse order depending on the related functions. Other implementations may also be included within the scope of preferred embodiments of the present disclosure.

Conditional languages, especially "can", "may", "may", or "may", have different meanings unless otherwise stated or in the context in which they are used. Unless understood, it generally conveys that a particular embodiment may include, but is not required, of a particular feature, element and / or step. Thus, such a conditional language may require features, elements and / or steps in any one or more embodiments, or one or more embodiments may or may not have user input or prompting. Regardless, it does not generally mean that it necessarily contains logic to determine whether or not these features, elements and / or steps are included, or whether or not to be implemented in a particular embodiment. ..

It should be emphasized that the embodiments of the present invention described above are merely possible embodiments and have been described only for the purpose of clearly understanding the principles of the present invention. Many modifications and modifications may be made for the aforementioned embodiments (s) of the invention without substantially departing from the spirit and principles of the invention. All such modifications and variations are included herein within the scope of the present disclosure and the present invention and are protected by the following claims.