Comparison of enterprise and user authentication standards and protocols IAM related standards and protocols for cloud computing services

"IT168 book" This article extracts from the Zhou Hongpo "cloud computing Security and privacy". In the previous section, we established the requirements and benefits of the IAM principles and practices for applying standards to cloud computing services. In this section, we will discuss the criteria for IAM, which is the catalyst for the enterprise to adopt cloud computing services. Organizations that are currently evaluating cloud computing services based on business and operational guidelines should take into account the commitment of cloud computing service providers and support for identity and access management standards.

iam standard and norm of 5.7.1 mechanism

The following IAM standards and specifications will help organizations implement effective, efficient user access management practices and processes in cloud computing. In terms of user and access management, the challenges facing cloud users are grouped into the following four categories:

1. How do you avoid replicating identities, attributes, and certificates and providing users with a single sign-on user experience? Security Assertion Markup Language (SAML).

2. How to automate the provision of cloud computing services for user accounts and automate user access and removal processes? Service Supply Markup Language (SPML).

3. How should the user account be provided with the appropriate permissions and the user's rights to administer permissions? Extensible Access Control Markup Language (XACML).

4. How do I authorize cloud computing services x to access data in cloud services Y without disclosing certificates? Open identity (OAuth).

5.7.1.1 Security Assertion Markup Language (SAML)

SAML is the most sophisticated and widely used cloud computing user based on the browser identity of the unified single sign-on specification family. Once the user has authenticated the identity service, they are free to access the cloud computing services provided in the trusting domain, thus avoiding the single sign-on program dedicated to cloud computing. Because of the SAML support Agent (single sign-on), users can choose to implement strong authentication (multifactor authentication) for certain cloud computing services by using a risk-based authentication strategy. The use of the IDP (identity provider) of the organization can be easily achieved, supporting strong authentication and accreditation. By enforcing strong authentication technologies such as dual-factor authentication, users are less susceptible to phishing attacks that are steadily growing on the Internet. Strong certification of cloud computing services is also desirable for protecting user certificates from Man-in-the-middle attacks, such as when a computer or browser is compromised, causing users to suffer Trojans and botnets. By supporting the SAML standards for delegated authentication mode, cloud computing service providers can delegate authentication policies to user agencies. In short, SAML will make it unnecessary for cloud computing service providers to understand the user's authentication requirements.

Figure 5-3 illustrates how to log on to Google Apps via a browser single point. The picture explains the specific steps of the Google Federated user single sign-on process.

▲ Figure 5-3: Single sign-on processing steps with SAML

1. An organization's users try to access apps on Google, such as Gmail, Start Pages, or other Google services.

2. Google generates a SAML authentication request. The SAML request is encoded and embedded in the URL (Uniform Resource Locator), and the body's IDP supports a single sign-on service. The relay status parameters that contain the Google application encoding URL that the user is attempting to access are also embedded in the single sign-on URL. This relay state parameter means an opaque identifier that is returned without modification and checking.

3. Google sends a redirect URL to the user's browser. The redirect URL includes a coded SAML authentication request that should be submitted to the Organization's IDP service.

4. IdP encodes the SAML request and extracts the URL for Google statement consumer Service (ACS) and user target URL (relay state parameters). The next IDP authentication user. IdP can authenticate users by asking for valid login certificates or by checking valid session cookies.

5. IdP generates a SAML response containing the user name of the authenticated user. In accordance with the SAML 2.0 specification, this response is a digital signature using the partner public and private Dsa/rsa keys.

6. IdP codes the SAML reply as well as the relay status parameters, and returns this information to the user's browser. IdP provides a mechanism for the browser to submit this information to the Google Statement User Service. For example, an IdP can embed a SAML reply and a target URL and generate a table, and then provide a button that the user clicks to submit to Google. IdP can also include JavaScript on the page and automatically submit the form to Google.

7. Google claims that the user Service uses the IDP public key to authenticate the SAML reply. If a reply is successfully validated, the user Service is declared to redirect users to the destination URL.

8. The user redirects to the target URL and logs in to Google Apps.

5.7.1.2 Service Supply Markup Language (SPML)

SPML is an xml-based framework that drives organizational development from structured information standards to Exchange user, resource, and service provisioning information among cooperative organizations. SPML is an emerging standard that can help organizations automate the creation of user identities for cloud computing services (for example, applications or services running on a customer's web site request a salesforce.com to create a new account). When SPML can be used, the organization should use it to open user accounts and profiles in cloud computing services. If SPML is supported, software as a service (SaaS) provider can be "instant open" to create accounts for new users in real time (as opposed to pre-registered users). In this mode, cloud computing service providers extract the attributes of new users from SPML tags, quickly create SPML information, and pass requirements to users to open services to increase user identities in cloud computing user databases.

The adoption of SPML can standardize and automate the access and rights of users or systems so that users do not lock in private solutions.

Figure 5-4 depicts a SPML use case in which the human resources system requests the user in cloud computing to open the system using the SPML request. In the diagram, the Human Resources system record (request authority) is a SPML Web service client that interacts with a provider of services to SPML users in the cloud computing service provider, which is responsible for providing user service in cloud computing services (user-launched service objectives).

▲ Diagram 5-4:SPML use case

5.7.1.3 extensible Access Control Markup Language (XACML)

XACML is a common xml-based access control language for policy management and access decisions, which is approved by the structured Information Standards Drive organization. It provides an XML schema for the common policy language to protect any type of resources and to make access decisions on those resources. The XACML standard not only provides a model for policy language, but also proposes a processing environment model for managing policies and access judgments. The XACML also provides a request/reply protocol that the application environment can use to communicate with decision points. The replies to the request for access are also defined using XML.

Most applications (network applications or others) have built-in authorization modules that grant or deny access to specific application features or resources, based on the permissions assigned to the user. In a centrally managed identity and access management architecture, application-specific authorization patterns (silos) make it difficult to describe the access rights of individual users across all applications. Therefore, the goal of XACML is to provide a standardized language, access control method, and policy execution across all applications to implement a common authorization standard. These authorization decisions are based on various authorization policies and rules focused on user roles and job functions. In short, the implementation of a common recognized standard allows for a unified authorization policy (for example, a common, agreed-upon standard policy for multiple services).

Figure 5-5 depicts the interactions among health care participants with unique roles (granted permissions) to access sensitive cases stored in health-care applications.

▲ Diagram 5-5:XACML use case

Figure 5-5 illustrates the specific steps for the XACML use case:

1. Health-care applications manage a variety of hospital colleagues (physicians, registered nurses, nurse assistants and health care supervisors) who access a variety of case elements. This application relies on the policy execution Point (PEP) and gives the request to the policy execution point.

2. The policy implementation point is actually an interface to the application environment. It accepts access requests and evaluates them with the help of decision points (PDP) and then allows or denies access to resources (health care Records).

3. The policy implementation point sends the request to the decision point. The decision point is the main decision point of the access request, the decision point collects all the necessary information from the available information resources and decides what kind of access is given. Decision points should be located on trusted networks and use strong access control policies, such as corporate trusted networks that are protected with enterprise firewalls.

4. After the assessment, the decision point sends the XACML response to the policy implementation point.

5. The policy implementation point fulfils its responsibility to implement decisions on the authorization of Decision points.

The demand reply protocol uses XACML information as its payload to enable interaction in this manner. In this way, the XACML is used to communicate the assessment of the policy and to respond to the decision of the request.

5.7.1.4 Open identity authentication (OAuth)

OAuth is a new certification standard that allows users to share private resources (such as photos, videos, contact lists, and bank accounts) with another cloud computing service provider that they store in other cloud computing service providers without presenting authentication information (such as username and password). OAuth is an open protocol that is established to provide a simple and standard way for desktops, mobile, and network applications by enabling authorization through the Secure Application Programming Interface (API). For application developers, OAuth is a way to publish and interact with protected data. For cloud computing service providers, OAuth provides a way for users to access their data on other providers while protecting their account certificates.

Within the enterprise, OAuth may play an important role in implementing a single sign-on to a trusted service provider by deploying a Web Service single sign-on mode. OAuth drives a pair of service authorizations to interact without requiring a clear identity syndication structure. Like OpenID (open authentication system), OAuth's starting point is a consumer-centric world, and it helps user services access user data across providers. Google has released a hybrid version of the OpenID and OAuth protocols, incorporating the licensing and certification processes and enhanced availability with fewer steps. Google's Gdata API announces support for OAuth. (GData also supports the Security Assertion markup language to achieve browser single sign-on.) )

Figure 5-6 depicts the sequence of interactions between users, partner network applications, Google services, and end users.

▲ Diagram 5-6:oauth use case

1. User network applications Contact Google Licensing Services to require a request token for one or more Google services.

2. Google verifies the content, ensures that the Web application is registered, and responds with an unauthorized request token.

3. Network application reference request token, redirect end user to Google Licensing page.

4. On the Google Licensing page, users are prompted to log in to the user account (for verification), and then grant or reject limited access to their Google service data by the network application.

5. Users decide whether to grant or deny access to network applications. If the user denies access, the user is redirected to the Google page instead of returning to the Web application.

6. If the user grants access, the authentication service redirects the user to the specified page of the Web application registered through Google. Redirection includes authorized request tokens.

7. Network application transfer request to Google Licensing service, replacement authorization request token for access token.

8. Google verifies the request and returns a valid access token.

9. Network application delivery request to the Google service under discussion. A request is signed, and the request contains an access token.

10. If the Google Service identification token, the requested data will be provided.

123 Next