定义

An Identity Broker is an intermediary service that connects multiple service providers with different identity providers. As an intermediary service, the identity broker is responsible for creating a trust relationship with an external identity provider in order to use its identities to access internal services exposed by service providers.

一个中间层服务，通过多个不同的身份验证服务，来连接多个系统间的业务服务。

它负责和外部系统身份验证提供者建立信任关系，获取外部系统的安全令牌，从而给内部系统访问外部系统服务资源创造信任授权。

An identity provider is usually based on a specific protocol that is used to authenticate and communicate authentication and authorization information to their users. It can be a social provider such as Facebook, Google or Twitter. It can be a business partner whose users need to access your services. Or it an be a cloud-based identity service that you want to integrate with.

身份验证提供者一般基于专用协议和用户交换验证和授权信息。它可以是社交服务供应商，像Facebook，Google或者Twitter。也可以是访问你内部服务的业务伙伴。或者是你想集成的云端的身份认证服务。

常用协议如下，

• SAML v2.0
• OpenID Connect v1.0
• OAuth v2.0

概览

Identity Broker Flow

1. User is not authenticated and requests a protected resource in a client application.
2. The client applications redirects the user to Red Hat Single Sign-On to authenticate.
3. At this point the user is presented with the login page where there is a list of identity providers supported by a realm.
4. User selects one of the identity providers by clicking on its respective button or link.
5. Red Hat Single Sign-On issues an authentication request to the target identity provider asking for authentication and the user is redirected to the login page of the identity provider. The connection properties and other configuration options for the identity provider were previously set by the administrator in the Admin Console.
6. User provides his credentials or consent in order to authenticate in the identity provider.
7. Upon a successful authentication by the identity provider, the user is redirected back to Red Hat Single Sign-On with an authentication response. Usually this response contains a security token that will be used by Red Hat Single Sign-On to trust the authentication performed by the identity provider and retrieve information about the user.
8. Now Red Hat Single Sign-On is going to check if the response from the identity provider is valid. If valid, it will import and create a new user or just skip that if the user already exists. If it is a new user, Red Hat Single Sign-On may ask the identity provider for information about the user if that info doesn’t already exist in the token. This is what we call identity federation. If the user already exists Red Hat Single Sign-On may ask him to link the identity returned from the identity provider with his existing account. We call this process account linking. What exactly is done is configurable and can be specified by setup of First Login Flow . At the end of this step, Red Hat Single Sign-On authenticates the user and issues its own token in order to access the requested resource in the service provider.
9. Once the user is locally authenticated, Red Hat Single Sign-On redirects the user to the service provider by sending the token previously issued during the local authentication.
10. The service provider receives the token from Red Hat Single Sign-On and allows access to the protected resource.

Note

Different protocols may require different authentication flows. At this moment, all the identity providers supported by Red Hat Single Sign-On use a flow just like described above. However, despite the protocol in use, user experience should be pretty much the same.

不同的协议类型可能用到不同的认证流程

As you may notice, at the end of the authentication process Red Hat Single Sign-On will always issue its own token to client applications. What this means is that client applications are completely decoupled from external identity providers. They don’t need to know which protocol (eg.: SAML, OpenID Connect, OAuth, etc) was used or how the user’s identity was validated. They only need to know about Red Hat Single Sign-On.

客户端应用程序和外部身份认证提供商完全的解耦，它们不需要知道认证是通过什么协议类型完成的。因为这一切都由Identity Broker代理做了，和认证供应商的沟通都由其完成。

实例

1. Employee enters their username and password.
2. The application calls an identity broker. Then broker captures username and password.
3. The identity broker make use of the organization's LDAP directory to validate the employee's identity. 
4. The identity broker calls the new GetFederationToken function using IAM user Credentials. The call must include an IAM policy and a duration (1 to 36 hours), along with a policy that specifies the permissions to be granted to the temporary security credentials.
5. The Security Token Service confirms that the policy of the IAM user making the call to GetFederationToken gives the permission to create new tokens and then return 4 values to the application: An access key, a secret access key, a token, and a duration (the token's lifetime)
6. The identity broker returns the temporary security credentials to the reporting application.
7. The data storage application uses the temporary credentials (including the token) to make request to Amazon S3.
8. Amazon S3 uses IAM to verify that the credentials allow the requested operation on the given S3 bucket and key.
9. IAM provides S3 with the go-ahead to perform the requested operation.

配置

参考

Red Hat Single Sign-On -> 7.0 -> Server Administration GuideChapter -> 12. Identity Brokering

AWS STS