text: Server Administration Guide
  For Use with Red Hat Single Sign-On Continuous Delivery 7.3.0.cd04
  Abstract
  Chapter 1. Overview Resource Provider library or SAML 2.0 Service Provider library.
  1.2. How Does Security Work?
  There are some key concepts and terms you should be aware of.
  Chapter>
  Chapter 3. Admin Console
  The bulk of your administrative tasks will be done through the Red Hat Single Sign-On Admin Console. You can go to the console url directly at
  Login Page
  Enter the username and password you created on the Welcome Page or the
  add-user-keycloak script in the bin directory. This will bring you to the Red Hat Single Sign-On Admin Console.
  Admin Console
  The left drop down menu allows you to pick a realm you want to manage or to create a new one. The right drop down menu allows you to view your user account or logout. If you are curious about a certain feature, button, or field within the Admin Console, simply hover your mouse over any question mark
  ? icon. This will pop up tooltip text to describe the area of the console you are interested in. The image above shows the tooltip in action.
  3.1. The Master Realm
  When you boot Red Hat Single Sign-On for the first time Red Hat Single Sign-On each individual new realm you create. Each realm has its own dedicated Admin Console that you can log into with local accounts. This guide talks more about this in the Dedicated Realm Admin Consoles chapter.
  3.2. Create.
  Add Realm Menu
  >>IMAGE.
  Create Realm
  After creating the realm you are brought back to the main Admin Console page. The current realm will now be set to the realm you just created. You can switch between managing different realms by doing a mouse over on the top left corner drop down menu.
  3.3..
  To configure Red Hat Single Sign-On so long as they stick to private IP addresses like
  localhost,
  127.0.0.1,
  10.0.x.x,
  192.168.x.x, and
  172.16.x.x. If you try to access Red Hat Single Sign-On from a non-private IP address you will get an error.
  - none
  - Red Hat Single Sign-On does not require SSL. This should really only be used in development when you are playing around with things and don’t want to bother configuring SSL on your server.
  - all requests
  - Red Hat Single Sign-On requires SSL for all IP addresses.
  3.4. Clearing Server Caches
  Red Hat Single Sign-On will cache everything it can in memory within the limits of your JVM and/or the limits you’ve configured it for. If the Red Hat Single Sign-On database is modified Red Hat Single Sign-On usually uses for verify signatures of particular external entity) from the Admin Console by going to the
  Realm Settings left menu item and the
  Cache tab.
  Cache tab
  Just click the
  clear button on the cache you want to evict.
  3.5. Email Settings
  Red Hat Single Sign-On sends emails to users to verify their email address, when they forget their passwords, or when an admin needs to receive notifications about a server event. To enable Red Hat Single Sign-On to send emails you need to provide Red Hat Single Sign-On with your SMTP server settings. This is configured per realm. Go to the
  Realm Settings left menu item and click the
  - Host
  Hostdenotes the SMTP server hostname used for sending emails.
  - Port
  Portdenotes the SMTP server port.
  - From
  Fromdenotes the address used for the
  FromSMTP-Header for the emails sent.
  - From Display Name
  From Display Nameallows to configure a user friendly email address aliases (optional). If not set the plain
  Reply Toemail address will be displayed.
  - Envelope From
  Envelope Fromdenotes the Bounce Address used for the
  Return-PathSM
  3.6. Themes and Internationalization
  Themes allow you to change the look and feel of any UI in Red Hat Single Sign-On. Red Hat Single Sign-On Admin Console.
  - Whenever Red Hat Single Sign-On has to send out an email, it uses templates defined in this theme to craft the email.
  The Server Developer Guide goes into how to create a new themes or modify existing ones.
  3.6.1. Internationalization
  Every UI screen is internationalized in Red Hat Single Sign-On. Developer Guide explains how you can offer additional languages.
  Chapter.1. Changing Passwords
  To change a user’s password, type in a new one. A
  Reset Password button will show up that you click after you’ve typed everything in. If the
  Temporary switch is on, this new password can only be used once and the user will be asked to change their password after they have logged in.
  Alternatively, if you have email set up, you can send an email to the user that asks them to reset their password. Choose
  Update Password from the
  Reset Actions list box and click
  Send Email. You can optionally set the validity of the e-mail link which defaults to the one preset in
  Tokens tab in the realm settings. The sent email contains a link that will bring the user to the update password screen.
  4.5.2. Changing OTPs
  You cannot configure One-Time Passwords for a specific user within the Admin Console. This is the responsibility of the user. If the user has lost their OTP generator all you can do is disable OTP for them on the
  Credentials tab. If OTP is optional in your realm, the user will have to go to the User Account Management service to re-configure a new OTP generator. If OTP is required, then the user will be asked to re-configure a new OTP generator when they log in.
  Like passwords, you can alternatively send an email to the user that will ask them to reset their OTP generator. Choose
  Configure OTP in the
  Reset Actions list box and click the
  Send Email button. The sent email contains a link that will bring the user to the OTP setup screen.
  4 a one-time password generator on their mobile device using either the Free OTP or Google Authenticator application.
  - Verify Email
  - When set, a user must verify that they have a valid email account. An email will be sent to the user with a link they have to click. Once this.6.1. Default Required Actions
  You can also specify required actions that will be added to an account whenever a new user is created, i.e. through the
  Add User button the user list screen, or via the user registration link on the login page. To specify the default required actions go to the
  Authentication left menu item and click on the
  Required Actions tab.
  Default Required Actions.7. Impersonation
  It is often useful for an admin to impersonate a user. For example, a user may be experiencing a bug in one of your applications and an admin may want to impersonate the user to see if they can duplicate the problem. Admins with the appropriate permission can impersonate a user. There are two locations an admin can initiate impersonation. The
  Near the bottom of the page you can see the
  Impersonate button. Click that to impersonate the user.
  When impersonating, if the admin and the user are in the same realm, then the admin will be logged out and automatically logged in as the user being impersonated. If the admin and user are not in the same realm, the admin will remain logged in, but additionally be logged in as the user in that user’s realm. In both cases, the browser will be redirected to the impersonated user’s User Account Management page.
  Any user with the realm’s
  impersonation role can impersonate a user. Please see the Admin Console Access Control chapter for more details on assigning administration permissions.
  4 Red Hat Single Sign-On Admin Console. Click the
  Authentication left menu item and go to the
  Flows tab. Select the
  Registration flow from the drop down list on this page.
  Registration Flow
  .
  Recaptcha Config Page
  The final step you have to do is to change some default HTTP response headers that Red Hat Single Sign-On sets. Red Hat Single Sign-On.
  Authorizing Ifram themes.
  Chapter Developer Guide:
  Login Tab
  Once you save this setting, a
  remember me checkbox will be displayed on the realm’s login page.
  Chapter. Users can have as short, as long, as complex, as insecure a password, as they want. Simple settings are fine for development or learning Red Hat Single Sign-On, but unacceptable in production environments._33<<:
  - Hashing Algorithm
  - Passwords are not stored as clear text. Instead they are hashed using standard hashing algorithms before they are stored or validated. Supported values are pbkdf2, pbkdf2-sha256 and pbkdf2-sha512.
  -.
  - Password Blacklist
  - This policy checks if a given password is contained in a blacklist file, which is potentially a very large file. Password blacklists are UTF-8 plain-text files with Unix line endings where every line represents a blacklisted password. The file name of the blacklist file must be provided as the password policy value, e.g.
  10_million_password_list_top_1000000.txt. Blacklist files are resolved against
  ${jboss.server.data.dir}/password-blacklists/by default. This path can be customized via the
  keycloak.password.blacklists.pathsystem property, or the
  blacklistsPathproperty of the
  passwordBlacklistpolicy SPI configuration._35<< all_36<<_37<<_38<<
  Add provider select box.
  Kerberos User Storage Provider
  . Cross-realm trust
  In the Kerberos V5 protocol, the
  realm is a set of Kerberos principals defined in the Kerberos database (typically LDAP server). The Kerberos protocol has a concept of cross-realm trust. For example, if there are 2 kerberos realms A and B, the cross-realm trust will allow the users from realm A to access resources (services) of realm B. This means that realm B trusts the realm A.
  Kerberos cross-realm trust
  The Red Hat Single Sign-On server has support for cross-realm trust. There are few things which need to be done to achieve this:
  - Configure the Kerberos servers for the cross-realm trust. This step is dependent on the concrete Kerberos server implementations used. In general, it is needed to add the Kerberos principal
  krbtgt/B@Ato both Kerberos databases of realm A and B. It is needed that this principal has same keys on both Kerberos realms. This is usually achieved when the principals have same password, key version number and there are same ciphers used in both realms. It is recommended to consult the Kerberos server documentation for more details.
  The cross-realm trust is unidirectional by default. If you want bidirectional trust to have realm A also trust realm B, you must also add the principal
  krbtgt/A@B to both Kerberos databases. However, trust is transitive by default. If realm B trusts realm A and realm C trusts realm B, then realm C automatically trusts realm A without a need to have principal
  krbtgt/C@A available. Some additional configuration (for example
  capaths) may be needed to configure on Kerberos client side, so that the clients are able to find the trust path. Consult the Kerberos documentation for more details.
  Configure Red Hat Single Sign-On server
  - If you use an LDAP storage provider with Kerberos support, you need to configure the server principal for realm B as in this example:
  HTTP/mydomain.com@B. The LDAP server must be able to find the users from realm A if you want users from realm A to successfully authenticate to Red Hat Single Sign-On, as Red Hat Single Sign-On server must be able to do SPNEGO flow and then find the users. For example, kerberos principal user
  john@Amust be available as a user in the LDAP under an LDAP DN such as
  uid=john,ou=People,dc=example,dc=com. If you want both users from realm A and B to authenticate, you need to ensure that LDAP is able to find users from both realms A and B. We want to improve this limitation in future versions, so you can potentially create more separate LDAP providers for separate realms and ensure that SPNEGO works for both of them.
  - If you use a Kerberos user storage provider (typically the Kerberos without LDAP integration), you need to configure the server principal as
  HTTP/mydomain.com@Band users from both Kerberos realms A and B should be able to authenticate.
  For the Kerberos user storage provider, it is recommended that there are no conflicting users among kerberos realms. If conflicting users exist, they will be mapped to the same Red Hat Single Sign-On user. This is also something, which we want to improve in future versions and provide some more flexible mappings from Kerberos principals to Red Hat Single Sign-On usernames.
  6.4
  6.5. X.509 Client Certificate User Authentication
  Red Hat Single Sign-On.5.1. Features
  - Supported Certificate Identity Sources
  - Match SubjectDN using regular expression
  - X500 Subject’s e-mail attribute
  - X500 Subject’s e-mail from Subject Alternative Name Extension (RFC822Name General Name)
  -.
  Please notice that if we disable
  Login with email at realm settings, the same rules will be applied to certificate authentication. In other words, users won’t be able to log in using e-mail attribute.
  - Other Features: Extended Certificate Validation
  - Revocation status checking using CRL
  - Revocation status checking using CRL/Distribution Point
  - Revocation status checking using OCSP/Responder URI
  - Certificate KeyUsage validation
  - Certificate ExtendedKeyUsage validation
  6.5.2. Enable X.509 Client Certificate User Authentication
  The following sections describe how to configure WildFly/Undertow and the Red Hat Single Sign-On Server to enable X.509 client certificate authentication.
  - Enable mutual SSL in WildFly
  See Enable SSL and SSL for the instructions how to enable SSL in WildFly.
  - Open RHSSO.5.3. Adding X.509 Client Certificate Authentication to a Browser Flow
  - Select a realm, click on Authentication link, select the "Browser" flow
  - Make a copy of the built validation. automatically sign in the user upon successful authentication.
  6.5.4. Adding X.509 Client Certificate Authentication to a Direct Grant Flow
  - Using Red Hat Single Sign-On admin console, click on "Authentication" and select the "Direct Grant" flow,
  - Make a copy of the build-in "Direct Grant" flow. You may want to give the new flow a distinctive name, i.e. "X509 Direct Grant",
  - Delete "Username Validation" and "Password" authenticators,
  - Click on "Add.5.5. Client certificate lookup
  When an HTTP request is sent directly to Red Hat Single Sign-On server, the JBoss EAP undertow subsystem will establish an SSL handshake and extract the client certificate. The client certificate will be then saved to the attribute
  javax.servlet.request.X509Certificate of the HTTP request, as specified in the servlet specification. The Red Hat Single Sign-On X509 authenticator will be then able to lookup the certificate from this attribute.
  However, when the Red Hat Single Sign-On server listens to HTTP requests behind a load balancer or reverse proxy, it may be the proxy server which extracts the client certificate and establishes the mutual SSL connection. A reverse proxy usually puts the authenticated client certificate in the HTTP header of the underlying request and forwards it to the back end Red Hat Single Sign-On server. In this case, Red Hat Single Sign-On must be able to look up the X.509 certificate chain from the HTTP headers instead of from the attribute of HTTP request, as is done for Undertow.
  If Red Hat Single Sign-On is behind a reverse proxy, you usually need to configure alternative provider of the
  x509cert-lookup SPI in RHSSO_HOME/standalone/configuration/standalone.xml. Along with the
  default provider, which looks up the certificate from the HTTP header, we also have two additional built-in providers:
  haproxy and
  apache, which are described next.
  6.5.5.1. HAProxy certificate lookup provider
  You can use this provider when your Red Hat Single Sign-On server is behind an HAProxy reverse proxy. Configure the server like this:
  <spi name="x509cert-lookup"> <default-provider>haproxy</default-provider> <provider name="haproxy" enabled="true"> <properties> <property name="sslClientCert" value="SSL_CLIENT_CERT"/> <property name="sslCertChainPrefix" value="CERT_CHAIN"/> <property name="certificateChainLength" value="10"/> </properties> </provider> </spi>
  In this example configuration, the client certificate will be looked up from the HTTP header,
  SSL_CLIENT_CERT, and the other certificates from its chain will be looked up from HTTP headers like
  CERT_CHAIN_0 ,
  CERT_CHAIN_1, …,
  CERT_CHAIN_9 . The attribute
  certificateChainLength is the maximum length of the chain, so the last one tried attribute would be
  CERT_CHAIN_9 .
  Consult the HAProxy documentation for the details of how the HTTP Headers for the client certificate and client certificate chain can be configured and their proper names.
  6.5.5.2. Apache certificate lookup provider
  You can use this provider when your Red Hat Single Sign-On server is behind an Apache reverse proxy. Configure the server like this:
  <spi name="x509cert-lookup"> <default-provider>apache</default-provider> <provider name="apache" enabled="true"> <properties> <property name="sslClientCert" value="SSL_CLIENT_CERT"/> <property name="sslCertChainPrefix" value="CERT_CHAIN"/> <property name="certificateChainLength" value="10"/> </properties> </provider> </spi>
  The configuration is same as for the
  haproxy provider. Consult the Apache documentation on mod_ssl and mod_headers for the details of how the HTTP Headers for the client certificate and client certificate chain can be configured and their proper names.
  6.5.5.3. Nginx certificate lookup provider
  You can use this provider when your Red Hat Single Sign-On server is behind an Nginx reverse proxy. Configure the server like this:
  <spi name="x509cert-lookup"> <default-provider>nginx</default-provider> <provider name="nginx" enabled="true"> <properties> <property name="sslClientCert" value="ssl-client-cert"/> <property name="sslCertChainPrefix" value="USELESS"/> <property name="certificateChainLength" value="2"/> </properties> </provider> </spi>
  NGINX SSL/TLS module does not expose the client certificate chain, so Keycloak NGINX certificate lookup provider is rebuilding it using the Keycloak truststore. Please populate Keycloak truststore using keytool CLI with all root and intermediate CA’s needed for rebuilding client certificate chain.
  Consult the NGINX documentation for the details of how the HTTP Headers for the client certificate can be configured. Example of NGINX configuration file :
  ... server { ... ssl_client_certificate trusted-ca-list-for-client-auth.pem; ssl_verify_client optional_no_ca; ssl_verify_depth 2; ... location / { ... proxy_set_header ssl-client-cert $ssl_client_escaped_cert; ... } ... }
  all certificates in trusted-ca-list-for-client-auth.pem must be added to Keycloak truststore.
  6.5.5.4. Other reverse proxy implementations
  We do not have built-in support for other reverse proxy implementations. However, it is possible that other reverse proxies can be made to behave in a similar way to
  apache or
  haproxy and that some of those providers can be used. If none of those works, you may need to create your own implementation of the
  org.keycloak.services.x509.X509ClientCertificateLookupFactory and
  org.keycloak.services.x509.X509ClientCertificateLookup provider. See the Server Developer Guide for the details on how to add your own provider.
  6.5.6. Troubleshooting
  - Dumping HTTP headers
  - If you want to view what the reverse proxy is sending to Keycloak, simply activate RequestDumpingHandler and consult
  server.logfile.
  - Enable TRACE logging under the logging subsystem
  ... <profile> <subsystem xmlns="urn:jboss:domain:logging:3.0"> ... <logger category="org.keycloak.authentication.authenticators.x509"> <level name="TRACE"/> </logger> <logger category="org.keycloak.services.x509"> <level name="TRACE"/> </logger>
  WARNING: Don't use RequestDumpingHandler or TRACE logging in production.
  - Red Hat Single Sign-On.
  Chapter 7. SSO Protocols
  The chapter gives a brief overview of the authentication protocols and how the Red Hat Single Sign-On authentication server and the applications it secures interact with these protocols.
  7.1. OpenID Connect
  OpenID Red Hat Single Sign-On access token it can use to invoke on other remote services on behalf of the user. Red Hat Single Sign-On.
  7.1.1..
  7.1.1.2. Red Hat Single Sign-On to be authenticated. The application passes along a callback URL (a redirect URL) as a query parameter in this browser redirect that Red Hat Single Sign-On will use when it finishes authentication.
  - Red Hat Single Sign-On authenticates the user and creates an identity and access token. Red Hat Single Sign-On redirects back to the application using the callback URL provided earlier and additionally adding the identity and access tokens as query parameters in the callback URL.
  - The application extracts the identity and access tokens from the callback URL.
  7.1.1.3..
  7.1.1.4..
  7.1.2. Red Hat Single Sign-On Server OIDC URI Endpoints
  Here’s a list of OIDC endpoints that the Red Hat Single Sign-On publishes. These URLs are useful if you are using a non-Red Hat Single Sign-On.
  7.2. SAML
  SAML 2.0 is a similar specification to OIDC but a lot older and more mature. It has its roots in SOAP and the plethora of WS-* specifications so it tends to be a bit more verbose than OIDC. SAML 2.0 is primarily an authentication protocol that works by exchanging XML documents between the authentication server and the application. XML signatures and encryption is used to verify requests and responses.
  There are really two types of use cases when using SAML. The first is an application that asks the Red Hat Single Sign-On defines a few different ways to exchange XML documents when executing the authentication protocol. The Redirect and Post bindings cover browser based applications. The ECP binding covers REST invocations. There are other binding types but Red Hat Single Sign-On only supports those three.
  7.2.1.1. Redirect Binding
  The Redirect Binding uses a series of browser redirect URIs to exchange information. This is a rough overview of how it works.
  - The user visits the application and the application finds the user is not authenticated. It generates an XML authentication request document and encodes it as a query param in a URI that is used to redirect to the Red Hat Single Sign-On server. Depending on your settings, the application may also digitally sign this XML document and also stuff this signature as a query param in the redirect URI to Red Hat Single Sign-On. This signature is used to validate the client that sent this request.
  - The browser is redirected to Red Hat Single Sign-On. The server extracts the XML auth request document and verifies the digital signature if required. The user then has to enter in their credentials to be authenticated.
  -.
  - The XML auth response document is then encoded as a query param in a redirect URI that brings the browser back to the application. The digital signature is also included as a query param.
  - The application receives the redirect URI and extracts the XML document and verifies the realm’s signature to make sure it is receiving a valid auth response. The information inside the SAML assertion is then used to make access decisions or display user data.
  7.2.1.2. POST Binding
  The SAML POST binding works almost the exact same way as the Redirect binding, but instead of GET requests, XML documents are exchanged by POST requests. The POST Binding uses JavaScript to trick the browser into making a POST request to the Red Hat Single Sign-On server or application when exchanging documents. Basically HTTP responses contain an HTML document that contains an HTML form with embedded JavaScript. When the page is loaded, the JavaScript automatically invokes the form. You really don’t need to know about this stuff, but it is a pretty clever trick.
  7.2.1.3. ECP
  ECP stands for "Enhanced Client or Proxy", a SAML v.2.0 profile which allows for the exchange of SAML attributes outside the context of a web browser. This is used most often for REST or SOAP-based clients.
  7.2.2. Red Hat Single Sign-On Server SAML URI Endpoints
  Red Hat Single Sign-On really only has one endpoint for all SAML requests.
  http(s)://authserver.host/auth/realms/{realm-name}/protocol/saml
  All bindings use this endpoint.
  7.3. OpenID Connect vs. SAML
  Choosing between OpenID Connect and SAML is not just a matter of using a newer protocol (OIDC) instead of the older more mature protocol (SAML).
  In most cases Red Hat Single Sign-On recommends using OIDC.
  SAML tends to be a bit more verbose than OIDC.
  Beyond verbosity of exchanged data, if you compare the specifications you’ll find that OIDC was designed to work with the web while SAML was retrofitted to work on top of the web. For example, OIDC is also more suited for HTML5/JavaScript applications because it is easier to implement on the client side than SAML. As tokens are in the JSON format, they are easier to consume by JavaScript. You will also it.
  7.4. Docker Registry v2 Authentication
  Docker Registry V2 Authentciation is an OIDC-Like protocol used to authenticate users against a Docker registry. Red Hat Single Sign-On’s implementation of this protocol allows for a Red Hat Single Sign-On the Red Hat Single Sign-On authentication server.
  This flow assumes that a
  docker login command has already been performed
  - Red Hat Single Sign-On authentication server.
  - The Red Hat Single Sign-On Red Hat Single Sign-On server, the registry validates the token and grants access to the requested resource (if appropriate).
  7.4.2. Red Hat Single Sign-On Docker Registry v2 Authentication Server URI Endpoints
  Red Hat Single Sign-On really only has one endpoint for all Docker auth v2 requests.
  http(s)://authserver.host/auth/realms/{realm-name}/protocol/docker-v2
  Chapter 8. Managing Clients
  Clients are entities that can request authentication of a user. Clients come in two forms. The first type of client is an application that wants to participate in single-sign-on. These clients just want Red Hat Single Sign-On to provide security for them. The other type of client is one that is requesting an access token so that it can invoke other services on behalf of the authenticated user. This section discusses various aspects around config.
  Clients
  This will bring you to the
  Add Client page.
  Add Client
  Enter in the
  Client ID of the client. This should be a simple alpha-numeric string that will be used in requests and in the Red Hat Single Sign-On database to identify the client. Next select
  openid-connect in the
  Client Protocol drop down box. Finally enter in the base URL of your application in the
  Root URL field and click
  Save. This will create the client and bring you to the client
  Settings tab.
  Client Settings
  Let’s walk through each configuration item on this page.
  Client ID
  This specifies an alpha-numeric string that will be used as the client identifier for OIDC requests..
  Access Type
  This defines the type of the OIDC client.
  - confidential
  - Confidential configuring correct redirect URIs for the client.
  - bearer-only
  - Bearer-only access type means that the application only allows bearer token requests. If this is turned on, this application cannot participate in browser logins.
  Root URL
  If Red Hat Single Sign-On uses any configured relative URLs, this value is prepended to them.
  Valid Redirect URIs
  This is a required field. Red Hat Single Sign-On Red Hat Single Sign-On specific client adapters, this is the callback endpoint for the client. The Red Hat Single Sign-On server will use this URI to make callbacks like pushing revocation policies, performing backchannel logout, and other administrative operations. For Red Hat Single Sign-On servlet adapters, this can be the root URL of the servlet application. For more information see Securing Applications and Services Guide.
  Web Origins
  This option centers around CORS which stands for Cross-Origin Resource Sharing. If browser JavaScript tries to make an AJAX HTTP request to a server whose domain is.
  Red Hat Single Sign-On Red Hat Single Sign-On client adapters support this feature. See Securing Applications and Services Guide for more information.
  To fill in the
  Web Origins data, enter in a base URL and click the + sign to add. Click the - sign next to URLs you want to remove. Remember that you still have to click the
  Save button!
  8.1.1. Advanced Settings
  OAuth 2.0 Mutual TLS Client Certificate Bound Access Token
  Mutual TLS binds an access token and a refresh token with a client certificate exchanged during TLS handshake. This prevents an attacker who finds a way to steal these tokens from exercising the tokens. This type of token is called a holder-of-key token. Unlike bearer tokens, the recipient of a holder-of-key token can verify whether the sender of the token is legitimate.
  If the following conditions are satisfied on a token request, Red Hat Single Sign-On will bind an access token and a refresh token with a client certificate and issue them as holder-of-key tokens. If all conditions are not met, Red Hat Single Sign-On rejects the token request.
  - The feature is turned on
  - A token request is sent to the token endpoint in an authorization code flow or a hybrid flow
  - On TLS handshake, Red Hat Single Sign-On requests a client certificate and a client send its client certificate
  - On TLS handshake, Red Hat Single Sign-On successfully verifies the client certificate
  To enable mutual TLS in Red Hat Single Sign-On, see Enable mutual SSL in WildFly.
  In the following cases, Red Hat Single Sign-On will verify the client sending the access token or the refresh token; if verification fails, Red Hat Single Sign-On rejects the token.
  - A token refresh request is sent to the token endpoint with a holder-of-key refresh token
  - A UserInfo request is sent to UserInfo endpoint with a holder-of-key access token
  - A logout request is sent to Logout endpoint with a holder-of-key refresh token
  Please see Mutual TLS Client Certificate Bound Access Tokens in the OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens for more details.
  WARNING: None of the keycloak client adapters currently support holder-of-key token verification. Instead, keycloak adapters currently treat access and refresh tokens as bearer tokens.
  8.1.2. Confidential Client Credentials
  If you’ve set the client’s access type to
  confidential in the client’s
  Settings tab, a new
  Credentials tab will show up. As part of dealing with this type of client you have to configure the client’s credentials.
  Credentials Tab
  The
  Client Authenticator list box specifies the type of credential you are going to use for your confidential client. It defaults to client ID and secret. The secret is automatically generated for you and the
  Regenerate Secret button allows you to recreate this secret if you want or need to.
  Alternatively, you can opt to use a signed Json Web Token (JWT) or x509 certificate validation (also called Mutual TLS) instead of a secret.
  Signed JWT
  When choosing this credential type you will have to also generate a private key and certificate for the client. The private key will be used to sign the JWT, while the certificate is used by the server to verify the signature. Click on the
  Generate new keys and certificate button to start this process.
  Generate Keys
  When you generate these keys, Red Hat Single Sign-On will store the certificate, and you’ll need to download the private key and certificate for your client to use. Pick the archive format you want and specify the password for the private key and store.
  You can also opt to generate these via an external tool and just import the client’s certificate.
  Import Certificate
  There are multiple formats you can import from, just choose the archive format you have the certificate stored in, select the file, and click the
  Import button.
  Finally note that you don’t even need to import certificate if you choose to
  Use JWKS URL . In that case, you can provide the URL where client publishes it’s public key in JWK format. This is flexible because when client changes it’s keys, Red Hat Single Sign-On will automatically download them without need to re-import anything on Red Hat Single Sign-On side.
  If you use client secured by Red Hat Single Sign-On adapter, you can configure the JWKS URL like assuming that is the root URL of your client application. See Server Developer Guide for additional details.
  For the performance purposes, Red Hat Single Sign-On caches the public keys of the OIDC clients. If you think that private key of your client was compromised, it is obviously good to update your keys, but it’s also good to clear the keys cache. See Clearing the cache section for more details.
  Signed JWT with Client Secret
  If you select this option in the
  Client Authenticator list box, you can use a JWT signed by client secret instead of the private key.
  This client secret will be used to sign the JWT by the client.
  X509 Certificate
  By enabling this option Red Hat Single Sign-On will validate if the client uses proper X509 certificate during the TLS Handshake.
  This option requires mutual TLS in Red Hat Single Sign-On, see Enable mutual SSL in WildFly.
  Import Certificate
  The validator checks also the certificate’s Subject DN field with configured regexp validation expression. For some use cases, it is sufficient to accept all certificates. In that case, you can use
  (.*?)(?:$) expression.
  There are two ways for Red Hat Single Sign-On to obtain the Client ID from the request. The first option is the
  client_id parameter in the query (described in Section 2.2 of the OAuth 2.0 Specification). The second option is to supply
  client_id as a query parameter.
  8.1.3. Service Accounts
  Each OIDC client has a built-in service account which allows it to obtain an access token. This is covered in the OAuth 2.0 specifiation Red Hat Single Sign-On admin console for this client. In tab
  Service Account Roles you can configure the roles available to the service account retrieved on behalf of this client. Remember that you must have the roles available in Role Scope Mappings (tab
  Scope) of this client as well, unless you have
  Full Scope Allowed on. As in a normal login, roles from access token are the intersection of:
  - Role scope mappings of particular client combined with the role scope mappings inherited from linked client scopes
  - specification.
  For example the POST invocation to retrieve a service account can look like this:
  The response would be this standard JSON document from the OAuth 2.0 specification." }
  The retrieved access token can be refreshed or logged out by an out-of-bound request.
  8.1.4. Audience Support
  The typical environment where the Red Hat Single Sign-On is deployed generally consists of a set of confidential or public client applications (frontend client applications) which use Red Hat Single Sign-On for authentication.
  There are also services (called Resource Servers in the OAuth 2 specification), which serve requests from frontend client applications and provide resources. These services typically require an Access token (Bearer token) to be sent to them to authenticate for a particular request. This token was previously obtained by the frontend application when it tries to log in against Red Hat Single Sign-On.
  In the environment where the trust among services is low, you may encounter this scenario:
  - A frontend client called
  my-appis required to be authenticated against Red Hat Single Sign-On.
  - A user is authenticated in Red Hat Single Sign-On. Red Hat Single Sign-On then issued tokens to the
  my-appapplication.
  - The application
  my-appused the token to invoke the service
  evil-service. The application needs to invoke
  evil-serviceas the service is able to serve some very useful data.
  - The
  evil-serviceapplication returned the response to
  my-app. However, at the same time, it kept the token previously sent to it.
  - The
  evil-serviceapplication then invoked another service called
  good-servicewith the previously kept token. The invocation was successful and
  good-servicereturned the data. This results in broken security as the
  evil-servicemisused the token to access other services on behalf of the client
  my-app.
  This flow may not be an issue in many environments with the high level of trust among services. However in other environments, where the trust among services is lower, this can be problematic.
  In some environments, this example work flow may be even requested behavior as the
  evil-service may need to retrieve additional data from
  good-service to be able to properly return the requested data to the original caller (my-app client). You may notice similarities with the Kerberos Credential Delegation. As with the Kerberos Credential Delegation, an unlimited audience is a mixed blessing as it is only useful when a high level of trust exists among services. Otherwise, it is recommended to limit audience as described next. You can limit audience and at the same time allow the
  evil-service to retrieve required data from the
  good-service. In this case, you need to ensure that both the
  evil-service and
  good-service are added as audiences to the token.
  To prevent any misuse of the access token as in the example above, it is recommended to limit Audience on the token and configure your services to verify the audience on the token. If this is done, the flow above will change, like this:
  - A frontend client called
  my-appis required to be authenticated against Red Hat Single Sign-On.
  - A user is authenticated in Red Hat Single Sign-On. Red Hat Single Sign-On then issued tokens to the
  my-appapplication. The client application already knows that it will need to invoke service
  evil-service, so it used
  scope=evil-servicein the authentication request sent to the Red Hat Single Sign-On server. See Client Scopes section for more details about the scope parameter. The token issued to the
  my-appclient contains the audience, as in
  "audience": [ "evil-service" ], which declares that the client wants to use this access token to invoke just the service
  evil-service.
  - The
  evil-serviceapplication served the request to the
  my-app. At the same time, it kept the token previously sent to it.
  - The
  evil-serviceapplication then invoked the
  good-servicewith the previously kept token. Invocation was not successful because
  good-servicechecks the audience on the token and it sees that audience is only
  evil-service. This is expected behavior and security is not broken.
  If the client wants to invoke the
  good-service later, it will need to obtain another token by issuing the SSO login with the
  scope=good-service. The returned token will then contain
  good-service as an audience:
  "audience": [ "good-service" ]
  and can be used to invoke
  good-service.
  8.1.4.1. Setup
  To properly set up audience checking:
  - Ensure that services are configured to check audience on the access token sent to them by adding the flag verify-token-audience in the adapter configuration. See Adapter configuration for details.
  - Ensure that when an access token is issued by Red Hat Single Sign-On, it contains all requested audiences and does not contain any audiences that are not needed. This is described below in more details.
  As an example, let us assume that you have a bearer-only client
  good-service. Set up Red Hat Single Sign-On for audience support like this:
  - Log in to the admin console. Go to the Client Scopes tab on the left and click Create.
  - Choose the Audience template.
  good-serviceas the requested audience
  Creating Audience Client Scope
  When the client scope is created, you should confirm that it contains:
  - An audience protocol mapper, which is used for adding the
  good-serviceas an audience to the access token. See the figure below.
  - Role scope mappings for all the client roles of
  good-serviceclient.
  Audience Protocol Mapper
  - From the Installation tab of the
  good-serviceclient, you can generate the adapter configuration and you can confirm that verify-token-audience option will be set to true. This indicates that the adapter will require verifying the audience if you use this generated configuration.
  - Finally, you need to ensure that the
  my-appfrontend client is able to request
  good-serviceas an audience in its tokens. On the
  my-appclient, click the Client Scopes tab. Then assign
  good-serviceas an optional (or default) client scope. See Client Scopes Linking section for more details.
  - You can optionally Evaluate Client Scopes and generate an example access token. If you do, notice that
  good-servicewill be added to the audience of the generated access token only if
  good-serviceis included in the scope parameter in the case you assigned it as an optional client scope.
  - In your
  my-appapplication, you must ensure that scope parameter is used with the value
  good-servicealways included when you want to issue the token for accessing the
  good-service. See the parameters forwarding section, if your application uses the servlet adapter, or the javascript adapter section, if your application uses the javascript adapter.
  8.1.4.2. Automatically add audience
  There is another way that the audience can be added to the token. In the default client scope roles, there is an Audience Resolve protocol mapper defined. This protocol mapper will check all the clients for which current token has at least one client role available. Then the client ID of each of those clients will be added as an audience automatically. This is especially useful if your service (usually bearer-only) clients rely on client roles. In the example in previous section, if all of those are true:
  - The
  good-serviceclient has any client role defined on itself
  - Target user has this client role assigned
  - Client
  my-apphas the role scope mappings for this role
  then the
  good-service will be automatically added as an audience. In this case, you do not need to set up the audience client scope as described in the previous section.
  If you are unsure what the correct audience and roles in the token will be, it is always a good idea to Evaluate Client Scopes in the admin console and do some testing around it.
  8.2. SAML Clients
  Red Hat Single Sign-On.
  Clients
  This will bring you to the
  Add Client page.
  Add Client
  Enter in the
  Client ID of the client. This is often a URL and will be the expected
  issuer value in SAML requests sent by the application. Next select
  saml in the
  Client Protocol drop down box. Finally enter in the
  Client SAML Endpoint URL. Enter the URL you want the Red Hat Single Sign-On.
  Client Settings
  - Client ID
  - This value must match the issuer value sent with AuthNRequests. Red Hat Single Sign-On, Red Hat Single Sign-On will sign the document using the realm’s private key.
  - Optimize REDIRECT signing key lookup
  - When turned on, the SAML protocol messages will include Red Hat Single Sign-On Red Hat Single Sign-On Red Hat Single Sign-On. Red Hat Single Sign-On will validate this signature using the client public key or cert set up in the
  SAML Keystab.
  - Force POST Binding
  - By default, Red Hat Single Sign-On will respond using the initial SAML binding of the original request. By turning on this switch, you will force Red Hat Single Sign-On Red Hat Single Sign-On Red Hat Single Sign-On Red Hat Single Sign-On is pull the Assertion Consumer URL from the request.
  - Base URL
  - If Red Hat Single Sign-On.
  8.2.1. IDP Initiated Login
  IDP Initiated Login is a feature that allows you to set up an endpoint on the Red Hat Single Sign-On server that will log you into a specific configure this on the
  Settings tab in the
  IDP Initiated SSO Relay State field.is set to a name that will be published as IDP Initiated Login initial point,
  Assertion Consumer Service POST Binding URLin the
  Fine Grain SAML Endpoint Configurationsectionattribute of the SAML client defined.2.2. SAML Entity Descriptors
  Instead of manually registering a SAML 2.0 client, you can import it via a standard SAML Entity Descriptor XML file. There is an
  Import option on the Add Client page.
  Add Client
  8.3. Client Links
  For scenarios where one wants to link from one client to another, Red Hat Single Sign-On provides a special redirect endpoint:
  /realms/realm_name/clients/{client-id}/redirect.
  If a client accesses this endpoint via an
  HTTP GET request, Red Hat Single Sign-On.4. OIDC Token and SAML Assertion Mappings
  Applications that receive ID Tokens, Access Tokens, or SAML assertions may need or want different user metadata and roles. Red Hat Single Sign-On allows you to define
  The new client does not have any built-in mappers, however it usually inherits some mappers from the client scopes as described in the client scopes section. Protocol mappers map things like, for example, email address to a specific config screen.
  Mapper Config
  The best way to learn about a config option is to hover over its tooltip.
  Most OIDC mappers also allow you to control where the claim gets put. You can opt to include or exclude the claim from both the id and access tokens by fiddling. Different config parameters will appear for different mapper types.
  8.5. Generating Client Adapter Config
  The Red Hat Single Sign-On can pre-generate configuration files that you can use to install a client adapter for in your application’s deployment environment. A number of adapter types are supported for both OIDC and SAML. Go to the
  Installation tab of the client you want to generate configuration for.
  Select the
  Format Option you want configuration generated for. All Red Hat Single Sign-On client adapters for OIDC and SAML are supported. The mod-auth-mellon Apache HTTPD adapter for SAML is supported as well as standard SAML entity descriptor files.
  8.6. Client Scopes
  If you have many applications you need to secure and register within your organization, it can become tedious to configure the protocol mappers and role scope mappings for each of these clients. Red Hat Single Sign-On allows you to define a shared client configuration in an entity called a client scope.
  Client scopes also provide support for the OAuth 2
  scope parameter, which allows a client application to request more or fewer claims or roles in the access token, according to the application needs.
  To create a client scope, follow these steps:
  - Go to the
  Client Scopesleft menu item. This initial screen shows you a list of currently defined client scopes.
  Client Scopes List
  - Click the
  Createbutton. Name the client scope and save. A client scope will have similar tabs to a regular clients. You can define protocol mappers and role scope mappings, which can be inherited by other clients, and which are configured to inherit from this client scope.
  8.6.1. Protocol
  When you are creating the client scope, you must choose the
  Protocol. Only the clients which use same protocol can then be linked with this client scope.
  Once you have created new realm, you can see that there is a list of pre-defined (builtin) client scopes in the menu.
  - For the SAML protocol, there is one builtin client scope,
  roles_list, which contains one protocol mapper for showing the roles list in the SAML assertion.
  - For the OpenID Connect protocol, there are client scopes
  profile,
  address,
  phone,
  offline_access,
  rolesand
  web-origins.
  The client scope,
  offline_access, is useful when client wants to obtain offline tokens. Learn about offline tokens in the Offline Access section or in the OpenID Connect specification, where scope parameter is defined with the value
  offline_access.
  The client scopes
  profile,
  address and
  phone are also defined in the OpenID Connect specification. These client scopes do not have any role scope mappings defined, but they have some protocol mappers defined, and these mappers correspond to the claims defined in the OpenID Connect specification.
  For example, when you click to open the
  phone client scope and open the
  Mappers tab, you will see the protocol mappers, which correspond to the claims defined in the specification for the scope
  phone.
  Client Scope Mappers
  When the
  phone client scope is linked to a client, that client automatically inherits all the protocol mappers defined in the
  phone client scope. Access tokens issued for this client will contain the phone number information about the user, assuming that the user has a defined phone number.
  Builtin client scopes contain exactly the protocol mappers as defined per the specification, however you are free to edit client scopes and create/update/remove any protocol mappers (or role scope mappings).
  The client scope
  roles is not defined in the OpenID Connect specification and it is also not added automatically to the
  scope claim in the access token. This client scope has some mappers, which are used to add roles of the user to the access token and possibly add some audiences for the clients with at least one client role as described in the Audience section.
  The client scope
  web-origins is also not defined in the OpenID Connect specification and not added to the
  scope claim. This is used to add allowed web origins to the access token
  allowed-origins claim.
  8.6.3. Link Client Scope with the Client
  Linking between client scope and client is configured in the
  Client Scopes tab of the particular client. There are 2 ways of linking between client scope and client.
  - Default Client Scopes
  - This is applicable for both OpenID Connect and SAML clients. Default client scopes are always applied when issuing OpenID Connect tokens or SAML assertions for this client. The client will inherit Protocol mappers and Role Scope Mappings defined on the client scope. For the OpenID Connect Protocol, the Mappers and Role Scope Mappings are always applied, regardless of the value used for the scope parameter in the OpenID Connect authorization request.
  - Optional Client Scopes
  - This is applicable only for OpenID Connect clients. Optional client scopes are applied when issuing tokens for this client, but only when they are requested by the
  scopeparameter in the OpenID Connect authorization request.
  8.6.3.1. Example
  For this example, we assume that the client has
  profile and
  phone and
  address are linked as optional client scopes. The client will use the value of the scope parameter when sending a request to the OpenID Connect authorization endpoint:
  scope=openid phone
  The scope parameter contains the string, with the scope values divided by space (which is also the reason why a client scope name cannot contain a space character in it). The value
  openid is the meta-value used for all OpenID Connect requests, so we will ignore it for this example. The token will contain mappers and role scope mappings from the client scopes
  profile,
  phone (an optional client scope requested by the scope parameter).
  8.6.4. Evaluating Client Scopes
  The tabs
  Mappers and
  Scope of the client contain the protocol mappers and role scope mappings declared solely for this client. They do not contain the mappers and scope mappings inherited from client scopes. However, it may be useful to see what the effective protocol mappers will be (protocol mappers defined on the client itself as well as inherited from the linked client scopes) and the effective role scope mappings used when you generate the token for the particular client.
  You can see all of these when you click the
  Client Scopes tab for the client and then open the sub-tab
  Evaluate. From here you can select the optional client scopes that you want to apply. This will also show you the value of the
  scope parameter, which needs to be sent from the application to the Red Hat Single Sign-On OpenID Connect authorization endpoint.
  Evaluating Client Scopes
  If you want to see how you can send a custom value for a
  scope parameter from your application, see the parameters forwarding section, if your application uses the servlet adapter, or the javascript adapter section, if your application uses the javascript adapter.
  8.6.4.1. Generating Example Tokens
  To see an example of a real access token, generated for the particular user and issued for the particular client, with the specified value of
  scope parameter, select the user from the
  Evaluate screen. This will generate an example token that includes all of the claims and role mappings used.
  8.6.5. Realm Default Client Scopes
  The
  Realm Default Client Scopes allow you to define set of client scopes, which will be automatically linked to newly created clients.
  Open the left menu item
  Client Scopes and then select
  Default Client Scopes.
  From here, select the client scopes that you want to add as
  Default Client Scopes to newly created clients and
  Optional Client Scopes to newly created clients.
  Default Client Scopes
  Once the client is created, you can unlink the default client scopes, if needed. This is similar to how you remove Default Roles.
  8.6.6. Scopes explained
  The term
  scope is used in Red Hat Single Sign-On on few places. Various occurences of scopes are related to each other, but may have a different context and meaning. To clarify, here we explain the various
  scopes used in Red Hat Single Sign-On.
  - Client scope
  - Referenced in this chapter. Client scopes are entities in Red Hat Single Sign-On, which are configured at the realm level and they can be linked to clients. The client scopes are referenced by their name when a request is sent to the Red Hat Single Sign-On authorization endpoint with a corresponding value of the
  scopeparameter. The details are described in the section about client scopes linking.
  - Role scope mapping
  - This can be seen when you open tab
  Scopeof a client or client scope. Role scope mapping allows you to limit the roles which can be used in the access tokens. The details are described in the Role Scope Mappings section.
  Chapter_69<<_71<<_72<<
  In the above example, we are about to assign the composite role
  developer that was created in the Composite Roles chapter.
  Effective Role Mappings
  _74<<
  As you can see from the screenshot, there are already a number of default roles set up by default.
  9.5. Role Scope Mappings role scope mappings becomes important.
  Role Scope Mappings_75<< scopes to define the same role scope mappings for a whole set of clients.
  Partial Scope
  Chapter 10. Groups
  Groups in Red Hat Single Sign-On
  .
  Group
  .
  User Groups
  .
  Group Membership
  10.1. Groups vs. Roles
  In the IT world the concepts of Group and Role are often blurred and interchangeable. In Red Hat Single Sign-On, Groups are just a collection of users that you can apply roles and attributes to in one place. Roles define a type of user and applications assign permission and access control to roles
  Aren’t Composite Roles also similar to Groups? Logically they provide the same exact functionality, but the difference
  Chapter 11. Admin Console Access Control and Permissions
  Each realm created on the Red Hat Single Sign realms.
  11.1.1. Global Roles
  There are two realm-level roles in the
  master realm. These are:
  - admin
  - create-realm
  Users with the
  admin role are super users and have full access to manage any realm on the server. Users with the
  create-realm role are allowed to create new realms. They will be granted full access to any new realm they create.
  11.1.2. Realm part of the administration console.
  Admins with the
  manage-users role will only be able to assign admin roles to users that they themselves have. So, if an admin has the
  manage-users role but doesn’t have the
  manage-realm role, they will not be able to assign this role.
  11.2. Dedicated Realm Admin Consoles
  Each realm has a dedicated Admin Console that can be accessed by going to the url
  /auth/admin/{realm-name}/console. Users within that realm can be granted realm management permissions by assigning specific user role mappings.
  Each realm has a built-in client called
  realm-management. You can view this client by going to the
  Clients left menu item of your realm. This client defines client-level roles that specify permissions that can be granted to manage the realm.
  - view-realm
  - view-users
  - view-clients
  - view-events
  - manage-realm
  - manage-users
  - create-client
  - manage-clients
  - manage-events
  - view-identity-providers
  - manage-identity-providers
  - impersonation
  Assign the roles you want to your users and they will only be able to use that
  11.3.1.2. Testing It Out.
  Next we log out of the master realm and re-login to the dedicated admin console for the
  test realm using the
  sales-admin as a username. This is located under
  /auth/admin/test/console.
  Sales Admin Login.
  Users Permissions.
  Add view-users
  11.3.2.1. Testing It Out.
  Next we log out of the master realm Keys
  The authentication protocols that are used by Red Hat Single Sign-On require cryptographic signatures and sometimes encryption. Red Hat Single Sign-On uses asymmetric key pairs, a private and public key, to accomplish this.
  Red Hat Single Sign-On has a single active keypair at a time, but can have several passive keys as well. The active keypair is used to create new signatures, while the passive keypairs can be used to verify previous signatures. This makes it possible to regularly rotate the keys without any downtime or interruption to users.
  When a realm is created a key pair and a self-signed certificate is automatically generated.
  To view the active keys for a realm select the realm in the admin console click on
  Realm settings then
  Keys. This will show the currently active keys for the realm. Red Hat Single Sign-On currently only supports RSA signatures so there is only one active keypair. In the future as more signature algorithms are added there will be more active keypairs.
  To view all available keys select
  All. This will show all active, passive and disabled keys. A keypair can have the status
  Active, but still not be selected as the currently active keypair for the realm. The selected active pair which is used for signatures is selected based on the first key provider sorted by priority that is able to provide an active keypair.
  11.4.1. Rotating keys
  It’s recommended to regularly rotate keys. To do so you should start by creating new keys with a higher priority than the existing active keys. Or create new keys with the same priority and making the previous keys passive.
  Once new keys are available all new tokens and cookies will be signed with the new keys. When a user authenticates to an application the SSO cookie is updated with the new signature. When OpenID Connect tokens are refreshed new tokens are signed with the new keys. This means that over time all cookies and tokens will use the new keys and after a while the old keys can be removed.
  How long you wait to delete old keys is a tradeoff between security and making sure all cookies and tokens are updated. In general it should be acceptable to drop old keys after a few weeks. Users that have not been active in the period between the new keys where added and the old keys removed will have to re-authenticate.
  This also applies to offline tokens. To make sure they are updated the applications need to refresh the tokens before the old keys are removed.
  As a guideline it may be a good idea to create new keys every 3-6 months and delete old keys 1-2 months after the new keys where created.
  11.4.2. Adding a generated keypair
  To add a new generated keypair select
  Providers and choose
  rsa-generated from the dropdown. You can change the priority to make sure the new keypair becomes the active keypair. You can also change the
  keysize if you want smaller or larger keys (default is 2048, supported values are 1024, 2048 and 4096).
  Click
  Save to add the new keys. This will generated a new keypair including a self-signed on the host select
  Providers and choose
  java-keystore from the dropdown. You can change the priority to make sure the new keypair becomes the active keypair.
  Fill in the values for
  Keystore,
  Keystore Password,
  Key Alias and
  Key Password and click on
  Save.
  11.4.5. Making keys passive
  Locate the keypair in
  Active or
  All then click on the provider in the
  Provider column. This will take you to the configuration screen for the key provider for the keys. Click on
  Active to turn it
  OFF, then click on
  Save. The keys will no longer be active and can only be used for verifying signatures.
  11.4.6. Disabling keys
  Locate the keypair in
  Active or
  All then click on the provider in the
  Provider column. This will take you to the generate new keypair as described above and then immediatelly remove the compromised keypair.
  Then to ensure that client applications won’t accept the tokens signed by the compromised key, you should update and push not-before policy for the realm, which is doable from the admin console. Pushing new policy will ensure that client applications won’t accept the existing tokens signed by the compromised key, but also the client application will be forced to download new keypair from the Red Hat Single Sign-On, hence the tokens signed by the compromised key won’t be valid anymore. Note that your REST and confidential clients must have set
  Admin URL, so that Red Hat Single Sign-On is able to send them the request about pushed not-before policy.
  Chapter 12. Identity can be a cloud-based identity service that you want to integrate with.-On.
  12.2. Default..
  12.8. Mapping Red Hat Single Sign-On_104<<
  There is a
  Create button on this page. Clicking on this create button allows you to create a broker mapper. Broker mappers can import SAML attributes or OIDC ID/Access token claims into user attributes and user role mappings.
  ).. Retrieving External IDP Tokens
  Red Hat Single Sign-On:
  GET /auth/realms/{realm}/broker/{provider_alias}/token HTTP/1.1 Host: localhost:8080 Authorization: Bearer <KEYCLOAK ACCESS TOKEN>
  An application must have authenticated with Red Hat Single Sign-On Red Hat Single Sign-On, you need to send the access token issued by Red Hat Single Sign-On.
  Chapter 13. User Session Management
  When a user logs into a realm, Red Hat Single Sign-On. by default and is not subject of
  SSO Session Idle timeout and
  SSO Session Max lifespan .). Moreover, if you enable the option
  Offline Session Max Limited, then the offline token expires after 60 days regardless of using the offline token for a refresh token action (this value,
  Offline Session Max lifespan, can also. Finally, the client needs to have an
  offline_access client scope added as an
  Optional client scope to it, which is done by default. request.
  Chapter 14. User Storage Federation
  Many companies have existing user databases that hold information about users and their passwords or other credentials. In many cases, it is just not possible to migrate off of those existing stores to a pure Red Hat Single Sign-On deployment. Red Hat Single Sign-On, Red Hat Single Sign-On Red Hat Single Sign-On runtime. This common user model can then be mapped to OIDC token claims and SAML assertion attributes.
  External user databases rarely have every piece of data needed to support all the features that Red Hat Single Sign-On has. In this case, the User Storage Provider can opt to store some things locally in the Red Hat Single Sign-On user store. Some providers even import the user locally and sync periodically with the external store. All this depends on the capabilities of the provider and how its configured. For example, your external user store may not support OTP. Depending on the provider, this OTP can be handled and stored by Red Hat Single Sign-On.
  14.1. Adding a Provider
  To add a storage provider go to the
  User Federation left menu item in the Admin Console.
  User Federation
  On the center, there is an
  Add Provider list box. Choose the provider type you want to add and you will be brought to the configuration page of that provider.
  14.2. Dealing with Provider Failures
  If a User Storage Provider fails, that is, if your LDAP server is down, you may have trouble logging in and may not be able to view users in the admin console. Red Hat Single Sign-On does not catch failures when using a Storage Provider to lookup a user. It will abort the invocation. So, if you have a Storage Provider with a higher priority that fails during user lookup, the login or user query will fail entirely with an exception and abort. It will not fail over to the next configured provider.
  The local Red Hat Single Sign-On user database is always searched first to resolve users before any LDAP or custom User Storage Provider. You may want to consider creating an admin account that is stored in the local Red Hat Single Sign-On user database just in case any problems come up in connecting to your LDAP and custom back ends.
  Each LDAP and custom User Storage Provider has an
  enable switch on its admin console page. Disabling the User Storage Provider will skip the provider when doing user queries so that you can view and login with users that might be stored in a different provider with lower priority. If your provider is using an
  import strategy and you disable it, imported users are still available for lookup, but only in read only mode. You will not be able to modify these users until you re-enable the provider.
  The reason why Red Hat Single Sign-On does not fail over if a Storage Provider lookup fails is that user databases often have duplicate usernames or duplicate emails between them. This can cause security issues and unforeseen problems as the user may be loaded from one external store when the admin is expecting the user to be loaded from another.
  14.3..3.1. Storage Mode
  By default, Red Hat Single Sign-On will import users from LDAP into the local Red Hat Single Sign-On user database. This copy of the user is either synchronized on demand, or through a periodic background task. The one exception to this is passwords. Passwords are not imported and password validation is delegated to the LDAP server. The benefits to this approach is that all Red Hat Single Sign-On features will work as any extra per-user data that is needed can be stored locally. This approach also reduces load on the LDAP server as uncached users are loaded from the Red Hat Single Sign-On database the 2nd time they are accessed. The only load your LDAP server will have is password validation. The downside to this approach is that when a user is first queried, this will require a Red Hat Single Sign-On database insert. The import will also have to be synchronized with your LDAP server as needed.
  Alternatively, you can choose not to import users into the Red Hat Single Sign-On user database. In this case, the common user model that the Red Hat Single Sign-On runtime uses is backed only by the LDAP server. This means that if LDAP doesn’t support a piece of data that a Red Hat Single Sign-On feature needs that feature will not work. The benefit to this approach is that you do not have the overhead of importing and synchronizing a copy of the LDAP user into the Red Hat Single Sign-On user database.
  This storage mode is controled by the
  Import Users switch. Set to
  On to import users.
  14.3. This option only applies when you are importing users from LDAP into the local Red Hat Single Sign-On user database.
  14.3.3. Other config options
  - Console Display Name
  - Name used when this provider is referenced in the admin console
  - Priority
  - The priority of this provider when looking up users or adding a user.
  - Sync Registrations
  - Does your LDAP support adding new users? Click this switch if you want new users created by Red Hat Single Sign-On in the admin console or the registration page to be added to LDAP.
  -.3.3.5. Sync of LDAP users to Red Hat Single Sign-On
  If you have import enabled, the LDAP Provider will automatically take care of synchronization (import) of needed LDAP users into the Red Hat Single Sign-On local database. As users log in, the LDAP.3.6. LDAP Mappers
  LDAP mappers are
  listeners, which are triggered by the LDAP are User Attribute mappers that map basic Red Hat Single Sign-On user attributes like username, firstname, lastname, and email to corresponding LDAP attributes. You are free to extend these and provide additional attribute mappings. Admin console provides tooltips, which should help with configuring the corresponding mappers.
  14
  For authentication with PAM Red Hat Single Sign-On uses JNA. Be sure you have this package installed:
  $ sudo yum install jna
  Use
  sssctl user-checks command to validate your setup:
  $ sudo sssctl user-checks admin -s keycloak
  14.6. Custom Providers
  Red Hat Single Sign-On does have an SPI for User Storage Federation that you can use to write your own custom providers. You can find documentation for this in our Server Developer Guide.
  Chapter_113<<
  To start storing events you’ll need to turn the
  Save Events switch to on under the
  Login Events Settings.
  Save Events
  _115<<_116<<_117<<
  In the
  Admin Events Settings section, turn on the
  Save Events switch.
  Admin Event Configuration
  _119<<
  If the
  Details column has a
  Representation box, you can click on that to view the JSON that was sent with that operation.
  Admin Representation
  You can also filter for the events you are interested in by clicking the
  Filter button.
  Admin Event Filter
  Chapter 16. Export and Import
  Red Hat Single Sign-On has the ability to export and import the entire database. This can be especially useful if you want to migrate your whole Red Hat Single Sign-On.
  If you have bigger amount of users in your database (500 or more), it’s highly recommended to export into directory rather than to single file. Exporting into single file may lead to the very big file. Also the directory provider is using separate transaction for each "page" (file with users), which leads to much better performance. Default count of users per file (and transaction) is 50, which showed us best performance, but you have possibility to override (See below). Exporting to single file is using one transaction per whole export and one per whole import, which results in bad performance with large amount of users.
  To export into unencrypted directory you can use:.
  The admin console import allows you to "overwrite" resources if you choose. Use this feature with caution, especially on a production system. Export .json files from Admin Console Export operation are generally not appropriate for data import since they contain invalid values for secrets.
  The admin console export allows you to export clients, groups, and roles. If there is a great number of any of these assets in your realm, the operation may take some time to complete. During that time server may not be responsive to user requests. Use this feature with caution, especially on a production system.
  Chapter_122<<_123<<_124<<.
  Chapter-On.
  Chapter 19. The Admin CLI
  In previous chapters, we described how to use the Red Hat Single Sign-On Admin Console to perform administrative tasks. You can also perform those tasks from the command-line interface (CLI) by using the Admin CLI command-line tool.
  19.1. Installing the Admin CLI
  The Admin CLI is packaged inside Red Hat Single Sign-On Server distribution. You can find execution scripts inside the
  bin directory.
  The Linux script is called
  kcadm.sh, and the script for Windows is called
  kcadm.bat.
  You can add the Red Hat Single Sign-On Red Hat Single Sign-On Server distribution.
  To avoid repetition, the rest of this document only gives Windows examples in places where the difference in the CLI is more than just in the
  kcadm command name.
  19.2. Using the Admin CLI
  The Admin CLI works by making HTTP requests to Admin REST endpoints. Access to them is protected and requires authentication.
  Consult the Admin REST API documentation for details about JSON attributes for specific endpoints. Red Hat Single Sign-On
  kcadm.config located under the user’s home directory. In Linux-based systems, the full path name is
  $HOME/.keycloak/kcadm.config. On Windows, the full path name is
  %HOMEPATH%\.keycloak\kcadm.config. You can use the
  --config option to point to a different file or location so you can maintain multiple authenticated sessions in parallel.
  It is best to perform operations tied to a single configuration file from a single thread.
  A list of realms is additionally filtered on the server to return only realms a user can see.
  Importing a realm from exported .json file
  - Use the
  createcommand on the
  partialImportendpoint.
  - Set
  ifResourceExiststo one of
  FAIL,
  SKIP,
  OVERWRITE.
  Use
  -fto submit the exported realm
  .jsonfile
  For example:
  $ kcadm.sh create partialImport -r demorealm2 -s ifResourceExists=FAIL -o -f demorealm.json
  If realm does not yet exist, you first have to create it.
  For example:
  $ kcadm.sh create realms -s realm=demorealm2 -s enabled=true
  Adding client roles to a group
  Use a dedicated
  add-roles command that can be used for adding realm roles and client roles.
  The following example adds the roles defined on the client
  realm-management -
  create-client role and the
  view-users role to the
  Group group (via the
  --gname option). The group can alternatively be specified by ID (via the
  --gid option).
  See Group operations for more operations that can be performed to groups.
  $ kcadm.sh add-roles -r demorealm --gname Group --cclientid realm-management --rolename create-client --rolename view-users
  Removing client roles from a group
  Use a dedicated
  remove-roles command to remove client roles from a group.
  Use the following example to remove two roles defined on the client
  realm management -
  create-client role and the
  view-users role from the
  Group group.
  See Group operations for more operations that can be performed to groups.
  $ kcadm.sh remove-roles -r demorealm --gname Group -
  Getting a Docker-v2 example configuration for a specific client
  Use a client’s ID to construct an endpoint URI that targets a specific client, such as
  clients/ID/installation/providers/docker-v2-compose-yaml.
  Note that response will be in
  .zip format.
  For example:
  $ kcadm.sh get -r demorealm > keycloak-docker-compose-yaml.zip
  Adding or removing roles for client’s service account
  Service account for the client is just a special kind of user account with username
  service-account-CLIENT_ID. You can perform user operations on this account as if it was a regular user.
  Filtering does not use exact matching. For example, the above example would match the value of the
  username attribute against the
  *testuser* pattern.
  You can also filter across multiple attributes by specifying multiple
  -q options, which return only users that match the condition for all the attributes.
  Getting a specific user
  Use a user’s ID to compose an endpoint URI, such as
  users/USER_ID.
  For example:
  $ kcadm.sh get users/0ba7a3fd-6fd8-48cd-a60b-2e8fd82d56e2 -r demorealm
  Updating a user
  Use the
  update command with the same endpoint URI that you used to get a specific user.
  For example, on:
  - --uusername --uusername(*)'
  The
  serverinfo endpoint is handled similarly to the
  realms endpoint in that it is not resolved relative to a target realm because it exists outside any specific realm.
  componentsendpoint.
  - Specify realm id as a value of the
  parentIdattribute.
  - Specify
  kerberosas the value of the
  providerIdattribute, and
  org.keycloak.storage.UserStorageProvideras the value of the
  providerTypeattribute.
  For example:
  $ kcadm.sh create components -r demorealm -s parentId=demorealmId -s id=demokerberos -s name=demokerberos -s providerId=kerberos -s providerType=org.keycloak.storage.UserStorageProvider -s 'config"]' -s 'config.cachePolicy=["DEFAULT"]'
  Getting a specific authentication flow
  Run the
  get command on the
  authentication/flows/FLOW_ID endpoint.
  For example:
  $ kcadm.sh get authentication/flows/febfd772-e1a1-42fb-b8ae-00c0566fafb8 -r demorealm
  Listing executions for a flow
  Run the
  get command on the
  authentication/flows/FLOW_ALIAS/executions endpoint.
  For example:
  $ kcadm.sh get authentication/flows/Copy%20of%20browser/executions -r demorealm
  Adding configuration to an execution
  - Get execution for a flow, and take note of its ID
  - Run the
  createcommand on the
  authentication/executions/{executionId}/configendpoint.
  For example:
  $ kcadm create "authentication/executions/a3147129-c402-4760-86d9-3f2345e401c7/config" -r examplerealm -b '{"config":{"x509-cert-auth.mapping-source-selection":"Match SubjectDN using regular expression","x509-cert-auth.regular-expression":"(.*?)(?:$)","x509-cert-auth.mapper-selection":"Custom Attribute Mapper","x509-cert-auth.mapper-selection.user-attribute-name":"usercertificate","x509-cert-auth.crl-checking-enabled":"","x509-cert-auth.crldp-checking-enabled":false,"x509-cert-auth.crl-relative-path":"crl.pem","x509-cert-auth.ocsp-checking-enabled":"","x509-cert-auth.ocsp-responder-uri":"","x509-cert-auth.keyusage":"","x509-cert-auth.extendedkeyusage":"","x509-cert-auth.confirmation-page-disallowed":""},"alias":"my_otp_config"}'
  Getting configuration for an execution
  - Get execution for a flow, and get its
  authenticationConfigattribute, containing the config ID.
  - Run the
  getcommand on the
  authentication/config/IDendpoint.
  For example:
  $ kcadm get "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm
  Updating configuration for an execution
  - Get execution for a flow, and get its
  authenticationConfigattribute, containing the config ID.
  - Run the
  updatecommand on the
  authentication/config/IDendpoint.
  For example:
  $ kcadm update "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm -b '{"id":"dd91611a-d25c-421a-87e2-227c18421833","alias":"my_otp_config","config":{"x509-cert-auth.extendedkeyusage":"","x509-cert-auth.mapper-selection.user-attribute-name":"usercertificate","x509-cert-auth.ocsp-responder-uri":"","x509-cert-auth.regular-expression":"(.*?)(?:$)","x509-cert-auth.crl-checking-enabled":"true","x509-cert-auth.confirmation-page-disallowed":"","x509-cert-auth.keyusage":"","x509-cert-auth.mapper-selection":"Custom Attribute Mapper","x509-cert-auth.crl-relative-path":"crl.pem","x509-cert-auth.crldp-checking-enabled":"false","x509-cert-auth.mapping-source-selection":"Match SubjectDN using regular expression","x509-cert-auth.ocsp-checking-enabled":""}}'
  Deleting configuration for an execution
  - Get execution for a flow, and get its
  authenticationConfigattribute, containing the config ID.
  - Run the
  deletecommand on the
  authentication/config/IDendpoint.
  For example:
  $ kcadm delete "authentication/config/dd91611a-d25c-421a-87e2-227c18421833" -r examplerealm
  12.4. Social Identity Providers
  For Internet facing applications, it is quite burdensome for users to have to register at your site to obtain access. It requires them to remember yet another username and password combination. Social identity providers allow you to delegate authentication to a semi-trusted and respected entity where the user probably already has an account. Red Hat Single Sign-On provides built-in support for the most common social networks out there, such as Google, Facebook, Twitter, GitHub, LinkedIn, Microsoft and StackOverflow.
  12.4.1. Bitbucket
  There are a number of steps you have to complete to be able to login to Bitbucket.
  First, open the
  Identity Providersleft menu item and select
  Bitbucketfrom the
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  Before you can click
  Save, you must obtain a
  Client IDand
  Client Secretfrom Bitbucket.
  You will the
  Redirect URIfrom this page in a later step, which you will provide to Bitbucket when you register Red Hat Single Sign-On as a client there.
  Add a New App
  To enable login with Bitbucket you must first register an application project in OAuth on Bitbucket Cloud.
  Bitbucket often changes the look and feel of application registration, so what you see on the Bitbucket site may differ. If in doubt, see the Bitbucket documentation.
  Click the
  Add consumerbutton.
  Register App
  Copy the
  Redirect URIfrom the Red Hat Single Sign-On
  Add Identity Providerpage and enter it into the
  Authorization callback URLfield on the Bitbucket
  Register a new OAuth applicationpage.
  On the same page, mark the
  Readboxes under
  Accountto allow your application to read user email.
  Bitbucket App Page
  When you are done registering, click
  Save. This will open the application management page in Bitbucket. Find the client ID and secret from this page so you can enter them into the Red Hat Single Sign-On
  Add identity providerpage.
  + +To finish, return to Red Hat Single Sign-On and enter them. Click
  Save.
  12.4.2. Facebook
  There are a number of steps you have to complete to be able to login to Facebook. First, go to the
  Facebookfrom the
  Identity Providersleft menu item and select
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  You can’t click save yet, as you’ll need to obtain a
  Client IDand
  Client Secretfrom Facebook. One piece of data you’ll need from this page is the
  Redirect URI. You’ll have to provide that to Facebook when you register Red Hat Single Sign-On as a client there, so copy this URI to your clipboard.
  To enable login with Facebook you first have to create a project and a client in the Facebook Developer Console.
  Facebook often changes the look and feel of the Facebook Developer Console, so these directions might not always be up to date and the configuration steps might be slightly different.
  Once you’ve logged into the console there is a pull down menu in the top right corner of the screen that says
  My Apps. Select the
  Add a New Appmenu item.
  Add a New App
  Select the
  Websiteicon. Click the
  Skip and Create App IDbutton.
  Create a New App ID
  The email address and app category are required fields. Once you’re done with that, you will be brought to the dashboard for the application. Click the
  Settingsleft menu item.
  Create a New App ID
  Click on the
  + Add Platformbutton at the end of this page and select the
  Websiteicon. Copy and paste the
  Redirect URIfrom the Red Hat Single Sign-On
  Add identity providerpage into the
  Site URLof the Facebook
  Websitesettings block.
  Specify Website
  After this it is necessary to make the Facebook app public. Click
  App Reviewleft menu item and switch button to "Yes".
  You will need also to obtain the App ID and App Secret from this page so you can enter them into the Red Hat Single Sign-On
  Add identity providerpage. To obtain this click on the
  Dashboardleft menu item and click on
  Showunder
  App Secret. Go back to Red Hat Single Sign-On and specify those items and finally save your Facebook Identity Provider.
  One config option to note on the
  Add identity providerpage for Facebook:
  12.4.3. GitHub
  There are a number of steps you have to complete to be able to login to GitHub. First, go to the
  Identity Providersleft menu item and select
  GitHubfrom the
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  You can’t click save yet, as you’ll need to obtain a
  Client IDand
  Client Secretfrom GitHub. One piece of data you’ll need from this page is the
  Redirect URI. You’ll have to provide that to GitHub when you register Red Hat Single Sign-On as a client there, so copy this URI to your clipboard.
  To enable login with GitHub you first have to register an application project in GitHub Developer applications.
  GitHub often changes the look and feel of application registration, so these directions might not always be up to date and the configuration steps might be slightly different.
  Add a New App
  Click the
  Register a new applicationbutton.
  Register App
  You’ll have to copy the
  Redirect URIfrom the Red Hat Single Sign-On
  Add Identity Providerpage and enter it into the
  Authorization callback URLfield on the GitHub
  Register a new OAuth applicationpage. Once you’ve completed this page you will be brought to the application’s management page.
  GitHub App Page
  You will need to obtain the client ID and secret from this page so you can enter them into the Red Hat Single Sign-On
  Add identity providerpage. Go back to Red Hat Single Sign-On and specify those items.
  12.4.4. GitLab
  There are a number of steps you have to complete to be able to login to GitLab.
  First, go to the
  Identity Providersleft menu item and select
  GitLabfrom the
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  Before you can click
  Save, you must obtain a
  Client IDand
  Client Secretfrom GitLab.
  You will the
  Redirect URIfrom this page in a later step, which you will provide to GitLab when you register Red Hat Single Sign-On as a client there.
  To enable login with GitLab you first have to register an application project in GitLab as OAuth2 authentication service provider.
  GitLab often changes the look and feel of application registration, so what you see on the GitLab site may differ. If in doubt, see the GitLab documentation.
  Add a New App
  Copy the
  Redirect URIfrom the Red Hat Single Sign-On
  Add Identity Providerpage and enter it into the
  Authorization callback URLfield on the GitLab
  Register a new OAuth applicationpage.
  GitLab App Page
  When you are done registering, click
  Save application. This will open the application management page in GitLab. Find the client ID and secret from this page so you can enter them into the Red Hat Single Sign-On
  Add identity providerpage.
  To finish, return to Red Hat Single Sign-On and enter them. Click
  Save.
  12.4.5. Google
  There are a number of steps you have to complete to be able to login to Google. First, go to the
  Googlefrom the
  Identity Providersleft menu item and select
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  You can’t click save yet, as you’ll need to obtain a
  Client IDand
  Client Secretfrom Google. One piece of data you’ll need from this page is the
  Redirect URI. You’ll have to provide that to Google when you register Red Hat Single Sign-On as a client there, so copy this URI to your clipboard.
  To enable login with Google you first have to create a project and a client in the Google Developer Console. Then you need to copy the client id and secret into the Red Hat Single Sign-On Admin Console.
  Google often changes the look and feel of the Google Developer Console, so these directions might not always be up to date and the configuration steps might be slightly different.
  Let’s see first how to create a project with Google.
  Log in to the Google Developer Console.
  Google Developer Console
  Click the
  Create Projectbutton. Use any value for
  Project nameand
  Project IDyou want, then click the
  Createbutton. Wait for the project to be created (this may take a while). Once created you will be brought to the project’s dashboard.
  Dashboard
  To be able to retrieve the profiles of Google users, you need to turn on the Google+ APIs. Select the
  Enable and manage APIsand click the
  Google+ APIlink.
  APIs
  Click the
  Enablebutton on this page. You will get a message that you must create the credentials of your project. So click the
  Go to Credentialsbutton.
  Go To Credentials
  You will then be brought to the credentials page.
  If you logout in the middle of this, there is a menu in the top left hand corner. Select
  API Managerand it will bring you to your desired screen.
  You will then be asked to specify what credentials you need and what type of data you will be accessing.
  Add Credentials
  Web serverand
  User dataand click the
  What credentials do I need?button.
  Create OAuth ID
  Next you’ll need to create an OAuth 2.0 client ID. Specify the name you want for your client. You’ll also need to copy and paste the
  Redirect URIfrom the Red Hat Single Sign-On
  Add Identity Providerpage into the
  Authorized redirect URIsfield. After you do this, click the
  Create client IDbutton.
  When users log into Google from Red Hat Single Sign-On they will see a consent screen from Google which will ask the user if Red Hat Single Sign-On is allowed to view information about their user profile. The next Google config screen asks you for information about this screen.
  Once you click
  Doneyou will be brought to the
  Credentialspage. Click on your new OAuth 2.0 Client ID to view the settings of your new Google Client.
  Google Client Credentials
  You will need to obtain the client ID and secret from this page so you can enter them into the Red Hat Single Sign-On
  Add identity providerpage. Go back to Red Hat Single Sign-On and specify those items.
  One config option to note on the
  Add identity providerpage for Google:
  openid
  profile
  If your organization uses the G Suite and you want to restrict access to only members of your organization, you must enter the domain that is used for the G Suite into the
  Hosted Domainfield to enable it.
  12.4.6. LinkedIn
  There are a number of steps you have to complete to be able to login to LinkedIn. First, go to the
  LinkedInfrom the
  Identity Providersleft menu item and select
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  You can’t click save yet, as you’ll need to obtain a
  Client IDand
  Client Secretfrom LinkedIn. One piece of data you’ll need from this page is the
  Redirect URI. You’ll have to provide that to LinkedIn when you register Red Hat Single Sign-On as a client there, so copy this URI to your clipboard.
  To enable login with LinkedIn you first have to create an application in LinkedIn Developer Network.
  LinkedIn may change the look and feel of application registration, so these directions may not always be up to date.
  Developer Network
  Click on the
  Create Applicationbutton. This will bring you to the
  Create a New ApplicationPage.
  Create App
  Fill in the form with the appropriate values, then click the
  Submitbutton. This will bring you to the new application’s settings page.
  App Settings
  r_basicprofileand
  r_emailaddressin the
  Default Application Permissionssection. You’ll have to copy the
  Redirect URIfrom the Red Hat Single Sign-On
  Add Identity Providerpage and enter it into the
  OAuth 2.0
  Authorized Redirect URLsfield on the LinkedIn app settings page. Don’t forget to click the
  Updatebutton after you do this!
  You will then need to obtain the client ID and secret from this page so you can enter them into the Red Hat Single Sign-On
  Add identity providerpage. Go back to Red Hat Single Sign-On and specify those items.
  12.4.7. Microsoft
  There are a number of steps you have to complete to be able to login to Microsoft. First, go to the
  Identity Providersleft menu item and select
  Microsoftfrom the
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  You can’t click save yet, as you’ll need to obtain a
  Client IDand
  Client Secretfrom Microsoft. One piece of data you’ll need from this page is the
  Redirect URI. You’ll have to provide that to Microsoft when you register Red Hat Single Sign-On as a client there, so copy this URI to your clipboard.
  To enable login with Microsoft account you first have to register an OAuth application at Microsoft. Go to the Microsoft Application Registration url.
  Microsoft often changes the look and feel of application registration, so these directions might not always be up to date and the configuration steps might be slightly different.
  Register Application
  Enter in the application name and click
  Create application. This will bring you to the application settings page of your new application.
  Settings
  You’ll have to copy the
  Redirect URIfrom the Red Hat Single Sign-On
  Add Identity Providerpage and add it to the
  Redirect URIsfield on the Microsoft application page. Be sure to click the
  Add Urlbutton and
  Saveyour changes.
  Finally, you will need to obtain the Application ID and secret from this page so you can enter them back on the Red Hat Single Sign-On
  Add identity providerpage. Go back to Red Hat Single Sign-On and specify those items.
  From November 2018 onwards, Microsoft is removing support for the Live SDK API in favor of the new Microsoft Graph API. The Red Hat Single Sign-On Microsoft identity provider has been updated to use the new endpoints so make sure to upgrade to Red Hat Single Sign-On version 7.2.5 or later in order to use this provider. Furthermore, client applications registered with Microsoft under "Live SDK applications" will need to be re-registered in the Microsoft Application Registration portal to obtain an application id that is compatible with the Microsoft Graph API.
  12.4.8. OpenShift
  OpenShift Online is currently in the developer preview mode. This documentation has been based on on-premise installations and local
  minishiftdevelopment environment.
  There are a just a few steps you have to complete to be able to login to OpenShift. First, go to the
  Identity Providersleft menu item and select
  OpenShiftfrom the
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  Registering OAuth client
  You can register your client using
  occommand line tool.
  nameof your OAuth client. Passed as
  client_idrequest parameter when making requests to
  <openshift_master>/oauth/authorizeand
  <openshift_master>/oauth/token.
  secretis used as the
  client_secretrequest parameter.
  redirect_uriparameter specified in requests to
  <openshift_master>/oauth/authorizeand
  <openshift_master>/oauth/tokenmust be equal to (or prefixed by) one of the URIs in
  redirectURIs.
  grantMethodis used to determine what action to take when this client requests tokens and has not yet been granted access by the user.
  Use client ID and secret defined by
  oc createcommand to enter them back on the Red Hat Single Sign-On
  Add identity providerpage. Go back to Red Hat Single Sign-On and specify those items.
  Please refer to official OpenShift documentation for more detailed guides.
  12.4.9. PayPal
  There are a number of steps you have to complete to be able to login to PayPal. First, go to the
  Identity Providersleft menu item and select
  PayPalfrom the
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  You can’t click save yet, as you’ll need to obtain a
  Client IDand
  Client Secretfrom PayPal. One piece of data you’ll need from this page is the
  Redirect URI. You’ll have to provide that to PayPal when you register Red Hat Single Sign-On as a client there, so copy this URI to your clipboard.
  To enable login with PayPal you first have to register an application project in PayPal Developer applications.
  Add a New App
  Click the
  Create Appbutton.
  Register App
  You will now be brought to the app settings page.
  Do the following changes
  Target Sandboxswitch on the
  Add identity providerpage)
  Add identity providerpage.
  App Settings
  Redirect URIfrom the Red Hat Single Sign-On
  Add Identity Providerpage and enter it into the
  Return URLfield.
  Log In with PayPalcheckbox.
  Full namecheckbox under the personal information section.
  12.4.10. StackOverflow
  There are a number of steps you have to complete to be able to login to StackOverflow. First, go to the
  Identity Providersleft menu item and select
  StackOverflowfrom the
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  To enable login with StackOverflow you first have to register an OAuth application on StackApps. Go to registering your application on Stack Apps url and login.
  StackOverflow often changes the look and feel of application registration, so these directions might not always be up to date and the configuration steps might be slightly Red Hat Single Sign-On
  Add identity providerpage. Go back to Red Hat Single Sign-On and specify those items.
  12.4.11. Twitter
  There are a number of steps you have to complete to be able to login to Twitter. First, go to the
  Twitterfrom the
  Identity Providersleft menu item and select
  Add providerdrop down list. This will bring you to the
  Add identity providerpage.
  Add Identity Provider
  You can’t click save yet, as you’ll need to obtain a
  Client IDand
  Client Secretfrom Twitter. One piece of data you’ll need from this page is the
  Redirect URI. You’ll have to provide that to Twitter when you register Red Hat Single Sign-On as a client there, so copy this URI to your clipboard.
  To enable login with Twtter you first have to create an application in the Twitter Application Management.
  Register Application
  Click on the
  Create New Appbutton. This will bring you to the
  Create an Applicationpage.
  Register Application
  Enter in a Name and Description. The Website can be anything, but cannot have a
  localhostaddress. For the
  Callback URLyou must copy the
  Redirect URIfrom the Red Hat Single Sign-On
  Add Identity Providerpage.
  You cannot use
  localhostin the
  Callback URL. Instead replace it with
  127.0.0.1if you are trying to testdrive Twitter login on your laptop.
  After clicking save you will be brought to the
  Detailspage.
  App Details
  Next go to the
  Keys and Access Tokenstab.
  Keys and Access Tokens
  Finally, you will need to obtain the API Key and secret from this page and copy them back into the
  Client IDand
  Client Secretfields on the Red Hat Single Sign-On
  Add identity providerpage.