XtremeCloud SSO Product Guide
Table of Contents
-
Overview
1.1. Function
1.2. How does security work?
1.3. Core Concepts and Terms
-
Server Initialization
- Management Console 3.1. The Master Realm 3.2. Create a New Realm 3.3. SSL Mode 3.4. Clearing server cache 3.5. Email Settings 3.6. Themes and Internationalization 3.6.1. Internationalization
- User Management 4.1. Searching For Users 4.2. Creating New Users 4.3. User Attributes 4.4. User Credentials 4.4.1. Changing Passwords 4.4.2. Changing OTPs 4.5. Required Actions 4.5.1. Default Required Actions 4.5.2. Terms and Conditions 4.6. Impersonation 4.7. User Registration 4.7.1. reCAPTCHA Support
- Login Page Settings 5.1. Forgot Password 5.2. Remember Me
- Authentication 6.1. Password Policies 6.1.1. Password Policy Types 6.2. OTP Policies 6.2.1. TOTP vs. HOTP 6.2.2. TOTP Conguration Options 6.2.3. HOTP Conguration Options
6.2.3. HOTP Conguration Options
6.3. Authentication Flows
6.4. Executions
6.5. Kerberos
6.5.1. Setup of Kerberos server
6.5.2. Setup and conguration of XtremeCloud SSO server
6.5.3. Setup and conguration of client machines
6.5.4. Example setups
6.5.5. Credential Delegation
6.5.6. トラブルシューティング
6.6. 機能
6.6.1. Supported Certicate Identity Sources
6.6.2. Regular Expressions
6.6.3. Mapping certicate identity to an existing user
6.6.4. Other Features: Extended Certicate Validation
6.7. Enable X.509 Client Certicate User Authentication
6.7.1. Enable mutual SSL in WildFly
6.7.2. Enable https listener
6.8. Adding X.509 Client Certicate Authentication to a Browser Flow
6.8.1. Conguring X.509 Client Certicate Authentication
6.9. Adding X.509 Client Certicate Authentication to a Direct Grant Flow
6.10. トラブルシューティング
6.10.1. Direct Grant authentication with X.
- SSOプロトコル 7.1. Open ID Connect 7.1.1. OIDC Auth Flows 7.1.2. XtremeCloud SSO Server OIDC URI Endpoints 7.2. SAML 7.2.1. SAML Bindings 7.2.2. XtremeCloud SSO Server SAML URI Endpoints 7.3. OpenID Connect 対 SAML 7.4. Docker Registry v2 Authentication 7.4.1. Docker Auth Flow 7.4.2. XtremeCloud SSO Docker Registry v2 Authentication Server URI Endpoints
- Managing Clients 8.1. OIDC Clients 8.1.1. Condential Client Credentials 8.2. Service Accounts 8.3. SAML Clients
8.3. SAML Clients
8.3.1. IDP Initiated Login
8.3.2. SAMLエンティティ記述子
8.4. Client Links
8.5. OIDC Token and SAML Assertion Mappings
8.6. Generating Client Adapter Cong
8.7. Client Templates
- Roles 9.1. Realm Roles 9.2. Client Roles 9.3. Composite Roles 9.4. User Role Mappings 9.4.1. Default Roles 9.5. Client Scope
- Groups 10.1. Groups vs. Roles 10.2. Default Groups
- Admin Console Access Control and Permissions 11.1. Master Realm Access Control 11.1.1. Global Roles 11.1.2. Realm Specic Roles 11.2. Dedicated Realm Admin Consoles 11.3. Fine Grain Admin Permissions 11.3.1. Managing One Specic Client 11.3.2. Restrict User Role Mapping 11.3.3. Full List of Permissions 11.4. Realm Keys 11.4.1. Rotating keys 11.4.2. Adding a generated keypair 11.4.3. Adding an existing keypair and certicate 11.4.4. Loading keys from a Java Keystore 11.4.5. Making keys passive 11.4.6. Disabling keys 11.4.7. Compromised keys
- アイデンティティー・ブローカリング 12.1. ブローカリングの概要 12.2. デフォルトのアイデンティティー・プロバイダー 12.3. 共通設定 12.4. ソーシャル・アイデンティティー・プロバイダー
12.4. ソーシャル・アイデンティティー・プロバイダー
12.4.1. Google
12.4.2. Facebook
12.4.3. Twitter
12.4.4. Github
12.4.5. LinkedIn
12.4.6. Microsoft
12.4.7. PayPal
12.4.8. Do the following changes:
12.4.9. StackOverow
12.4.10. Openshift
12.5. OpenID Connect v1.0 Identity Providers
12.6. SAML v2.0 Identity Providers
12.6.1. SP Descriptor
12.7. Client Suggested Identity Provider
12.8. Mapping Claims and Assertions
12.9. Available User Session Data
12.10. First Login Flow
12.10.1. Default First Login Flow
12.11. Retrieving External IDP Tokens
- User Session Management 13.1. Administering Sessions 13.1.1. Logout All Limitations 13.1.2. Application Drilldown 13.1.3. User Drilldown 13.2. Revocation Policies 13.3. Session and Token Timeouts 13.4. Oine Access
- User Storage Federation 14.1. Adding a Provider 14.2. LDAP and Active Directory 14.2.1. Storage Mode 14.2.2. Edit Mode 14.2.3. Other cong options 14.2.4. Connect to LDAP over SSL 14.2.5. Sync of LDAP users to XtremeCloud SSO 14.2.6. LDAP Mappers 14.3. SSSD and FreeIPA Identity Management Integration 14.3.1. FreeIPA/IdM Server
14.3.1. FreeIPA/IdM Server
14.3.2. SSSD and D-Bus
14.3.3. Enabling the SSSD Federation Provider
14.4. Conguring a Federated SSSD Store
14.5. Custom Providers
- Auditing and Events 15.1. Login Events 15.1.1. Event Types 15.1.2. Event Listener 15.2. Admin Events
- Export and Import 16.1. Admin console export/import
- User Account Service 17.1. Themeable
- Relaxation of threat model 18.1. Password speculation: brute force attack 18.1.1. Password Policies 18.2. Clickjacking 18.3. SSL/HTTPS Requirement 18.4. CSRF Attacks 18.5. Unspecic Redirect URIs 18.6. Compromised Access and Refresh Tokens 18.7. Compromised Authorization Code 18.8. Open redirectors 18.9. Password database compromised 18.10. Limiting Scope 18.11. SQL Injection Attacks
- Admin CLI 19.1. Installing Admin CLI 19.2. Using Admin CLI 19.3. Authenticating 19.4. Working with alternative congurations 19.5. Basic operations, and resource URIs 19.6. Realm operations 19.7. Role operations 19.8. Client operations 19.9. User operations 19.10. Group operations 19.11. Identity Providers operations
19.11. Identity Providers operations
19.12. Storage Providers operations
19.13. Adding mappers
19.14. Authentication operations
1. Overview
XtremeCloud SSO is a single sign-on solution for web applications and RESTful web services. The purpose of XtremeCloud SSO is to simplify security and protect application and services deployed by application developers within the organization. Security features that developers usually have to write on their own are immediately oered and can easily be adjusted to suit individual requirements within the organization. XtremeCloud SSO provides a customizable user interface for login, registration, system administration, account management. XtremeCloud SSO can also connect to existing LDAP and Active Directory servers and use it as an integrated platform. You can also delegate authentication to third-party identity providers like Facebook and Google+.
1.1. Function
Single sign-on and single sign-out for browser applications.
Support for OpenID Connect.
Support for OAuth 2.0.
SAML support.
Identity Brokering - Authentication by an external OpenID Connect or an identity provider that
supports SAML.
Social login - Log in via Google, GitHub, Facebook, Twitter and other social networks.
User Federation - User synchronization from LDAP or Active Directory.
Kerberos collaboration - Authentication collaboration for users who have logged in to Kerberos
server.
A management console for centralized management of users, roles, role mappings, clients and
settings.
Account management console to allow users to centralize their accounts.
Theme correspondence - Customizable for all user screens, allowing integration of applications and
branding.
Two-factor authentication - Support for TOTP / HOTP using Google Authenticator and FreeOTP.
Login ow - Self registration, password recovery, e-mail verication, forced password change
function etc. by the user of the option itself.
Session management - Administrators and users can view and manage their sessions.
Token Mapper - Specify how to reect user attributes, roles, etc. on tokens and statements.
Realm, application, per-user Not-before revocation policy.
CORS support - Client adapters that are compatible with CORS.
Service Provider Interface (SPI) - Numerous SPIs to customize various aspects of the server.
Authentication ow, user federation provider, protocol mapper, and many others.
Client adapter such as JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring etc.
Support for any platform / language with OpenID Connect resource provider library or SAML 2.
service provider library.
1.2. How does security work?
XtremeCloud SSOはあなたのネットワークに配置される、あなたが管理する分離されたサーバーです。アプリケーシ ョンはこのサーバーを指すように設定され、このサーバーによって保護されます。XtremeCloud SSOはアプリケーシ ョンを保護するために、Open ID Connect(http://openid.net/connect/)やSAML 2. (http://saml.xml.org/saml-specications)といった標準プロトコルを採用しています。ユーザーは完全にアプリ ケーションから分離され、アプリケーションはユーザーのクレデンシャルを見ることも決してないため、こ の点は重要です。代わりに、アプリケーションには、暗号化署名されたアイデンティティー・トークンまた はアサーションが与えられます。これらのトークンはユーザー名、住所、電子メール、および、その他プロ ファイルデータといったアイデンティティー情報を持つことができます。また、権限データを保持すること も可能でアプリケーションは認可決定を行うことも可能です。これらのトークンはRESTベースのサービスに 対して安全な呼び出しを行うためにも使用できます。
1.3. Core Concepts and Terms
There are some key concepts and terms you should be aware of before attempting to use XtremeCloud SSO to secure your web applications and REST services.
users
Users are entities that are able to log into your system. They can have attributes associated with
themselves like email, username, address, phone number, and birth day. They can be assigned group
membership and have specic roles assigned to them.
authentication
The process of identifying and validating a user.
authorization
The process of granting access to a user.
credentials
Credentials are pieces of data that XtremeCloud SSO uses to verify the identity of a user. Some examples are
passwords, one-time-passwords, digital certicates, or even ngerprints.
roles
Roles identify a type or category of user. Admin, user, manager, and employee are all typical roles
that may exist in an organization. Applications often assign access and permissions to specic roles
rather than individual users as dealing with users can be too ne grained and hard to manage.
user role mapping
A user role mapping denes a mapping between a role and a user. A user can be associated with zero
or more roles. This role mapping information can be encapsulated into tokens and assertions so that
applications can decide access permissions on various resources they manage.
composite roles
A composite role is a role that can be associated with other roles. For example a superuser
composite role could be associated with the sales-admin and order-entry-admin roles. If a user
is mapped to the superuser role they also inherit the sales-admin and order-entry-admin
roles.
groups
Groups manage groups of users. Attributes can be dened for a group. You can map roles to a group
as well. Users that become members of a group inherit the attributes and role mappings that group
denes.
realms
A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a
realm. Realms are isolated from one another and can only manage and authenticate the users that
they control.
clients
Clients are entities that can request XtremeCloud SSO to authenticate a user. Most often, clients are
applications and services that want to use XtremeCloud SSO to secure themselves and provide a single sign-on
solution. Clients can also be entities that just want to request identity information or an access token
so that they can securely invoke other services on the network that are secured by XtremeCloud SSO.
client adapters
Client adapters are plugins that you install into your application environment to be able to
communicate and be secured by XtremeCloud SSO. XtremeCloud SSO has a number of adapters for dierent platforms
that you can download. There are also third-party adapters you can get for environments that we
don’t cover.
consent
Consent is when you as an admin want a user to give permission to a client before that client can
participate in the authentication process. After a user provides their credentials, XtremeCloud SSO will pop up
a screen identifying the client requesting a login and what identity information is requested of the
user. User can decide whether or not to grant the request.
client templates
When a client is registered you need to enter conguration information about that client. It is often
useful to store a template to make create new clients easier. XtremeCloud SSO provides the concept of a client
template for this.
client role
Clients can dene roles that are specic to them. This is basically a role namespace dedicated to the
client.
identity token
A token that provides identity information about the user. Part of the OpenID Connect specication.
access token
A token that can be provided as part of an HTTP request that grants access to the service being
invoked on. This is part of the OpenID Connect and OAuth 2.0 specication.
assertion
Information about a user. This usually pertains to an XML blob that is included in a SAML
authentication response that provided identity metadata about an authenticated user.
service account
Each client has a built-in service account which allows it to obtain an access token.
direct grant
A way for a client to obtain an access token on behalf of a user via a REST invocation.
protocol mappers
For each client you can tailor what claims and assertions are stored in the OIDC token or SAML
assertion. You do this per client by creating and conguring protocol mappers.
session
When a user logs in, a session is created to manage the login session. A session contains information
like when the user logged in and what applications have participated within single-sign on during that
session. Both admins and users can view session information.
user federation provider
XtremeCloud SSO can store and manage users. Often, companies already have LDAP or Active Directory
services that store user and credential information. You can point XtremeCloud SSO to validate credentials
from those external stores and pull in identity information.
identity provider
An identity provider (IDP) is a service that can authenticate a user. XtremeCloud SSO is an IDP.
identity provider federation
XtremeCloud SSO can be configured to delegate authentication to one or more IDPs. Social login via Facebook
or Google+ is an example of identity provider federation. You can also hook XtremeCloud SSO to delegate
authentication to any other Open ID Connect or SAML 2.0 IDP.
identity provider mappers
When doing IDP federation you can map incoming tokens and assertions to user and session
attributes. This helps you propagate identity information from the external IDP to your client
requesting authentication.
required actions
Required actions are actions a user must perform during the authentication process. A user will not
be able to complete the authentication process until these actions are complete. For example, an
admin may schedule users to reset their passwords every month. An update password required
action would be set for all these users.
authentication flows
Authentication ows are work ows a user must perform when interacting with certain aspects of the
system. A login ow can dene what credential types are required. A registration ow denes what
prole information a user must enter and whether something like reCAPTCHA must be used to lter
out bots. Credential reset ow denes what actions a user must do before they can reset their
password.
events
Events are audit streams that admins can view and hook into.
themes
Every screen provided by XtremeCloud SSO is backed by a theme. Themes dene HTML templates and
stylesheets which you can override as needed.
2. Server Initialization
After performing all the installation and conguration tasks dened in the Server Installation and Conguration Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_installation/), you will need to create an initial admin account. XtremeCloud SSO does not have any configured admin account out of the box. This account will allow you to create an admin that can log into the master realm’s administration console so that you can start creating realms, users and registering applications to be secured by XtremeCloud SSO.
If your server is accessible from localhost, you can boot it up and create this admin user by going to the http://localhost:8080/auth URL.
ウェルカムページ
Simply specify the username and password you want for this initial admin.
If you cannot access the server via a localhost address, or just want to provision XtremeCloud SSO from the command line you can do this with the … /bin/add-user-XtremeCloud SSO script.
add-user-XtremeCloud SSO script
The parameters are a little dierent depending if you are using the standalone operation mode or domain operation mode. For standalone mode, here is how you use the script.
Linux/Unix
Windows
For domain mode, you have to point the script to one of your server hosts using the -sc switch.
Linux/Unix
Windows
3. Management Console
Most of the management work is done by XtremeCloud SSO management console. You can access directly with the URL of http: // localhost: 8080 / auth / admin /.
$ .../bin/add-user-XtremeCloud SSO.sh -r master -u <username> -p <password>
> ...\bin\add-user-XtremeCloud SSO.bat -r master -u <username> -p <password>
$ .../bin/add-user-XtremeCloud SSO.sh --sc domain/servers/server-one/configuration -r master -u
<username> -p <password>
> ...\bin\add-user-XtremeCloud SSO.bat --sc domain/servers/server-one/configuration -r master -u
<username> -p <password>
Login page
add-user-XtremeCloud SSOEnter the user name and password created in the welcome page or the script in the bin directory. The XtremeCloud SSO Management Console page opens.
Admin console
左のドロップダウン・メニューで管理または新しく作成したいレルムを選択できます。右のドロップダウ
ン・メニューでは自身のユーザー・アカウントの参照やログアウトができます。管理コンソール内の特定の
機能、ボタンまたはフィールドについて興味がある場合は、クエスチョンマーク? アイコンにマウスオーバ
ーします。そうすると、興味のある当該コンソール関連を説明するツールチップ・テキストがポップアップ
表示されます。このとおりに実行すると、ツールチップは上記のようになります。
3.1. The Master Realm
When you boot XtremeCloud SSO for the rst time XtremeCloud SSO creates a pre-dened realm for you. This initial realm is the master realm. It is the highest level in the hierarchy of realms. Admin accounts in this realm have permissions to view and manage any other realm created on the server instance. When you dene your initial admin account, you create an account in the master realm. Your initial login to the admin console will also be via the master realm.
We recommend that you do not use the master realm to manage the users and applications in your organization. Reserve use of the master realm for super admins to create and manage the realms in your system. Following this security model helps prevent accidental changes and follows the tradition of permitting user accounts access to only those privileges and powers necessary for the successful completion of their current task.
It is possible to disable the master realm and dene admin accounts within 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 a New Realm
Creating a new realm is very simple. Mouse over the top left corner drop down menu that is titled with Master. If you are logged in the master realm this drop down menu lists all the realms created. The last entry of this drop down menu is always Add Realm. Click this to add a realm.
レルムの追加メニュー
This menu option will bring you to the Add Realm page. Specify the realm name you want to dene and click the Create button. Alternatively you can import a JSON document that denes your new realm. We’ll go over this in more detail in the Export and Import chapter.
レルムの作成
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 dierent realms by doing a mouse over on the top left corner drop down menu.
3.3. SSL Mode
Each realm has an SSL Mode associated with it. The SSL Mode denes the SSL/HTTPS requirements for interacting with the realm. Browsers and applications that interact with the realm must honor the SSL/HTTPS requirements dened by the SSL Mode or they will not be allowed to interact with the server.
XtremeCloud SSOは、デフォルトではSSL/HTTPSを処理するように設定されていません。XtremeCloud SSO
サーバー上、またはXtremeCloud SSOサーバーのフロントにあるリバースプロキシ上のいずれかで
SSLを有効にすることを強くおすすめします。
To congure the SSL Mode of your realm, you need to click on the Realm Settings left menu item and go to the Login tab.
Login Tab
The Require SSL option allows you to pick the SSL Mode you want. Here is an explanation of each mode:
external requests
Users can interact with XtremeCloud SSO 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 XtremeCloud SSO from a non-
private IP address you will get an error.
none
XtremeCloud SSO 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 conguring SSL on your server.
all requests
XtremeCloud SSOはすべてのIPアドレスに対してSSLを要求します。
3.4. サーバー・キャッシュのクリア
XtremeCloud SSO will cache everything it can in memory within the limits of your JVM and/or the limits you’ve configured it for. If the XtremeCloud SSO database is modied by a third party (i.e. a DBA) outside the scope of the server’s REST APIs or Admin Console there’s a chance parts of the in-memory cache may be stale. You can clear the realm cache, user cache or cache of external public keys (Public keys of external clients or Identity providers, which XtremeCloud SSO 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
XtremeCloud SSO sends emails to users to verify their email address, when they forget their passwords, or when an admin needs to receive notications about a server event. To enable XtremeCloud SSO to send emails you need to provide XtremeCloud SSO with your SMTP server settings. This is configured per realm. Go to the Realm Settings left menu item and click the Email tab.
Email Tab
Host
Host denotes the SMTP server hostname used for sending emails.
Port
Port denotes the SMTP server port.
From
From denotes the address used for the From SMTP-Header for the emails sent.
From Display Name
From Display Name allows to congure an user friendly email address aliases (optional). If not set
the plain From email address will be displayed in email clients.
Reply To
Reply To denotes the address used for the Reply-To SMTP-Header for the mails sent (optional). If
not set the plain From email address will be used.
Reply To Display Name
Reply To Display Name allows to congure an user friendly email address aliases (optional). If not
set the plain Reply To email address will be displayed.
Envelope From
Envelope From denotes the Bounce Address(https://en.wikipedia.org/wiki/Bounce_address) used for the
Return-Path SMTP-Header for the mails sent (optional).
As emails are used for recovering usernames and passwords it’s recommended to use SSL or TLS, especially if the SMTP server is on an external network. To enable SSL click on Enable SSL or to enable TLS click on Enable TLS. You will most likely also need to change the Port (the default port for SSL/TLS is 465).
If your SMTP server requires authentication click on Enable Authentication and insert the Username and Password.
3.6. Themes and Internationalization
Themes allow you to change the look and feel of any UI in XtremeCloud SSO. Themes are configured per realm. To change a theme go to the Realm Settings left menu item and click on the Themes tab.
Themes Tab
Pick the theme you want for each UI category and click Save.
Login Theme
Username password entry, OTP entry, new user registration, and other similar screens related to
login.
Account Theme
Each user has an User Account Management UI.
Admin Console Theme
The skin of the XtremeCloud SSO Admin Console.
Email Theme
Whenever XtremeCloud SSO has to send out an email, it uses templates dened in this theme to craft the
email.
The Server Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) goes into how to create a new themes or modify existing ones.
3.6.1. Internationalization
Every UI screen is internationalized in XtremeCloud SSO. The default language is English, but if you turn on the Internationalization switch on the Theme tab you can choose which locales you want to support and what the default locale will be. The next time a user logs in, they will be able to choose a language on the login page to use for the login screens, User Account Management UI, and Admin Console. The Server Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) explains how you can oer additional languages.
4. User Management
This section describes the administration functions for managing users.
4.1. Searching For Users
If you need to manage a specic user, click on Users in the left menu bar.
ユーザー
This menu option brings you to the user list page. In the search box you can type in a full name, last name, or email address you want to search for in the user database. The query will bring up all users that match your criteria. The View all users button will list every user in the system. This will search just local XtremeCloud SSO database and not the federated database (ie. LDAP) because some backends like LDAP don’t have a way to page through users. So if you want the users from federated backend to be synced into XtremeCloud SSO database you need to either:
Adjust search criteria. That will sync just the backend users matching the criteria into XtremeCloud SSO
database.
Go to User Federation tab and click Sync all users or Sync changed users in the page with
your federation provider.
See User Federation for more details.
4.2. Creating New Users
To create a user click on Users in the left menu bar.
ユーザー
This menu option brings you to the user list page. On the right side of the empty user list, you should see an Add User button. Click that to start creating your new user.
ユーザーの追加
The only required eld is Username. Click save. This will bring you to the management page for your new user.
4.3. User Attributes
Beyond basic user metadata like name and email, you can store arbitrary user attributes. Choose a user to manage then click on the Attributes tab.
ユーザー
Enter in the attribute name and value in the empty elds and click the Add button next to it to add a new eld. Note that any edits you make on this page will not be stored until you hit the Save button.
4.4. User Credentials
When viewing a user if you go to the Credentials tab you can manage a user’s credentials.
Credential Management
4.4.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.4.2. Changing OTPs
You cannot congure One-Time Passwords for a specic 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-congure a new OTP generator. If OTP is required, then the user will be asked to re-congure 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.5. Required Actions
Required Actions are tasks that a user must nish before they are allowed to log in. A user must provide their credentials before required actions are executed. Once a required action is completed, the user will not have to perform the action again. Here are an explanation of some of the built-in required action types:
パスワードの更新
When set, a user must change their password.
Configure OTP
When set, a user must congure 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 workow is successfully completed, they will be allowed to log
in.
Update Profile
This required action asks the user to update their prole information, i.e. their name, address, email,
and/or phone number.
Admins can add required actions for each individual user within the user’s Details tab in the Admin Console.
Setting Required Action
In the Required User Actions list box, select all the actions you want to add to the account. If you want to remove one, click the X next to the action name. Also remember to click the Save button after you’ve decided what actions to add.
4.5.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
Simply click the checkbox in the Default Action column of the required actions that you want to be executed when a brand new user logs in.
4.5.2. Terms and Conditions
Many organizations have a requirement that when a new user logs in for the rst time, they need to agree to the terms and conditions of the website. XtremeCloud SSO has this functionality implemented as a required action, but it requires some conguration. For one, you have to go to the Required Actions tab described earlier and enable the Terms and Conditions action. You must also edit the terms.ftl le in the base login theme. See the Server Developer Guide (http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for more information on extending and creating themes.
4.6. 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 rst is on the Users list tab.
ユーザー
You can see here that the admin has searched for jim. Next to Jim’s account you can see an impersonate button. Click that to impersonate the user.
Also, you can impersonate the user from the user Details tab.
User Details
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.7. User Registration
You can enable XtremeCloud SSO to allow user self registration. When enabled, the login page has a registration link the user can click on to create their new account. Enabling registration is pretty simple. Go to the Realm Settings left menu and click it. Then go to the Login tab. There is a User Registration switch on this tab. Turn it on, then click the Save button.
Login Tab
After you enable this setting, a Register link should show up on the login page.
Registration Link
Clicking on this link will bring the user to the registration page where they have to enter in some user prole information and a new password.
Registration Form
You can change the look and feel of the registration form as well as removing or adding additional elds that must be entered. See the Server Developer Guide (http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for more information.
4.7.1. reCAPTCHA Support
To safeguard registration against bots, XtremeCloud SSO has integration with Google reCAPTCHA. To enable this you need to rst go to Google Recaptcha Website(https://developers.google.com/recaptcha/) and create an API key so that you can get your reCAPTCHA site key and secret. (FYI, localhost works by default so you don’t have to specify a domain).
Next, there are a few steps you need to perform in the XtremeCloud SSO Admin Console. Click the Authentication left menu item and go to the Flows tab. Select the Registration ow from the drop down list on this page.
Registration Flow
Set the ‘reCAPTCHA’ requirement to Required by clicking the appropriate radio button. This will enable reCAPTCHA on the screen. Next, you have to enter in the reCAPTCHA site key and secret that you generated at the Google reCAPTCHA Website. Click on the ‘Actions’ button that is to the right of the reCAPTCHA ow entry, then “Cong” link, and enter in the reCAPTCHA site key and secret on this cong page.
Recaptcha Cong Page
The nal step you have to do is to change some default HTTP response headers that XtremeCloud SSO sets. XtremeCloud SSO will prevent a website from including any login page within an iframe. This is to prevent clickjacking attacks. You need to authorize Google to use the registration page within an iframe. Go to
the Realm Settings left menu item and then go to the Security Defenses tab. You will need to add https://www.google.com to the values of both the X-Frame-Options and Content-Security- Policy headers.
Authorizing Iframes
Once you do this, reCAPTCHA should show up on your registration page. You may want to edit register.ftl in your login theme to muck around with the placement and styling of the reCAPTCHA button. See the Server Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for more information on extending and creating themes.
5. Login Page Settings
There are several nice built-in login page features you can enable if you need the functionality.
5.1. Forgot Password
If you enable it, users are able to reset their credentials if they forget their password or lose their OTP generator. Go to the Realm Settings left menu item, and click on the Login tab. Switch on the Forgot Password switch.
Login Tab
A forgot password link will now show up on your login pages.
Forgot Password Link
Clicking on this link will bring the user to a page where they can enter in their username or email and receive an email with a link to reset their credentials.
Forgot Password Page
The text sent in the email is completely congurable. You just need to extend or edit the theme associated with it. See the Server Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for more information.
When the user clicks on the email link, they will be asked to update their password, and, if they have an OTP generator set up, they will also be asked to recongure this as well. Depending on the security requirements of your organization you may not want users to be able to reset their OTP generator through email. You can change this behavior by going to the Authentication left menu item, clicking on the Flows tab, and selecting the Reset Credentials ow:
Reset Credentials Flow
If you do not want OTP reset, then just chose the disabled radio button to the right of Reset OTP.
5.2. Remember Me
If a logged in user closes their browser, their session is destroyed and they will have to log in again. You can set things up so that if a user checks a remember me checkbox, they will remain logged in even if the browser is closed. This basically turns the login cookie from a session-only cookie to a persistence cookie.
To enable this feature go to Realm Settings left menu item and click on the Login tab and turn on the Remember Me switch:
Login Tab
Once you save this setting, a remember me checkbox will be displayed on the realm’s login page.
Remember Me
6. 認証
レルムの認証を設定する際に注意すべき機能がいくつかあります。多くの組織には、厳密なパスワードと
OTPポリシーがありますが、管理コンソールの設定で実施することができます。認証には異なるクレデンシ
ャル・タイプを必要とする場合とそうでない場合があります。ユーザーにKerberos経由でログインするオプ ションを与えたり、さまざまな組み込みのクレデンシャル・タイプを無効または有効にしたりすることがで きます。この章では、これらすべてのトピックについてご説明します。
6.1. Password Policies
Each new realm created has no password policies associated with it. Users can have as short, as long, as complex, as insecure a password, as they want. Simple settings are ne for development or learning XtremeCloud SSO, but unacceptable in production environments. XtremeCloud SSO has a rich set of password policies you can enable through the Admin Console.
Click on the Authentication left menu item and go to the Password Policy tab. Choose the policy you want to add in the right side drop down list box. This will add the policy in the table on the screen. Choose the parameters for the policy. Hit the Save button to store your changes.
Password Policy
After saving your policy, user registration and the Update Password required action will enforce your new policy. An example of a user failing the policy check:
Failed Password Policy
If the password policy is updated, an Update Password action must be set for every user. An automatic trigger is scheduled as a future enhancement.
6.1.1. Password Policy Types
Here’s an explanation of each policy type:
HashAlgorithm
Passwords are not stored as clear text. Instead they are hashed using standard hashing algorithms
before they are stored or validated. The only built-in and default algorithm available is PBKDF2. See
the Server Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) on how to plug in your
own algorithm. Note that if you do change the algorithm, password hashes will not change in storage
until the next time the user logs in.
Hashing Iterations
This value species the number of times a password will be hashed before it is stored or veried. The
default value is 20,000. This hashing is done in the rare case that a hacker gets access to your
password database. Once they have access to the database, they can reverse engineer user
passwords. The industry recommended value for this parameter changes every year as CPU power
improves. A higher hashing iteration value takes more CPU power for hashing, and can impact
performance. You’ll have to weigh what is more important to you. Performance or protecting your
passwords stores. There may be more cost eective ways of protecting your password stores.
Digits
The number of digits required to be in the password string.
Lowercase Characters
The number of lower case letters required to be in the password string.
Uppercase Characters
The number of upper case letters required to be in the password string.
Special Characters
The number of special characters like '?!#%$' required to be in the password string.
Not Username
When set, the password is not allowed to be the same as the username.
Regular Expression
Dene one or more Perl regular expression patterns that passwords must match.
Expire Password
The number of days for which the password is valid. After the number of days has expired, the user is
required to change their password.
Not Recently Used
This policy saves a history of previous passwords. The number of old passwords stored is
congurable. When a user changes their password they cannot use any stored passwords.
6.2. OTP Policies
XtremeCloud SSO has a number of policies you can set up for your FreeOTP or Google Authenticator One-Time Password generator. Click on the Authentication left menu item and go to the OTP Policy tab.
OTP Policy
Any policies you set here will be used to validate one-time passwords. When conguring OTP, FreeOTP and Google Authenticator can scan a QR code that is generated on the OTP set up page that XtremeCloud SSO has. The bar code is also generated from information configured on the OTP Policy tab.
6.2.1. TOTP vs. HOTP
There are two dierent algorithms to choose from for your OTP generators. Time Based (TOTP) and Counter Based (HOTP). For TOTP, your token generator will hash the current time and a shared secret. The server validates the OTP by comparing the all hashes within a certain window of time to the submitted value. So, TOTPs are valid only for a short window of time (usually 30 seconds). For HOTP a shared counter is used instead of the current time. The server increments the counter with each successful OTP login. So, valid OTPs only change after a successful login.
TOTP is considered a little more secure because the matchable OTP is only valid for a short window of time while the OTP for HOTP can be valid for an indeterminate amount of time. HOTP is much more user friendly as the user won’t have to hurry to enter in their OTP before the time interval is up. With the way XtremeCloud SSO has implemented TOTP this distinction becomes a little more blurry. HOTP requires a database update every time the server wants to increment the counter. This can be a performance drain on the authentication server when there is heavy load. So, to provide a more ecient alternative, TOTP does not remember passwords used. This bypasses the need to do any DB updates, but the downside is that TOTPs can be re-used in the valid time interval. For future versions of XtremeCloud SSO it is planned that you will be able to congure whether TOTP checks older OTPs in the time interval.
6.2.2. TOTP Conguration Options
OTP Hash Algorithm
Default is SHA1, more secure options are SHA256 and SHA512.
Number of Digits
How many characters is the OTP? Short means more user friendly as it is less the user has to type.
More means more security.
Look Ahead Window
How many intervals ahead should the server try and match the hash? This exists so just in case the
clock of the TOTP generator or authentication server get out of sync. The default value of 1 is usually
good enough. For example, if the time interval for a new token is every 30 seconds, the default value
of 1 means that it will only accept valid tokens in that 30 second window. Each increment of this cong
value will increase the valid window by 30 seconds.
OTP Token Period
Time interval in seconds a new TOTP will be generated by the token generator. And, the time window
the server is matching a hash.
6.2.3. HOTP Conguration Options
OTP Hash Algorithm
Default is SHA1, more secure options are SHA256 and SHA512.
Number of Digits
How many characters is the OTP? Short means more user friendly as it is less the user has to type.
More means more security.
Look Ahead Window
How many counters ahead should the server try and match the hash? The default value is 1. This
exists to cover the case where the user’s counter gets ahead of the server’s. This can often happen as
users often increment the counter manually too many times by accident. This value really should be
increased to a value of 10 or so.
Initial Counter
What is the value of the initial counter?
6.3. Authentication Flows
An authentication ow is a container for all authentications, screens, and actions that must happen during login, registration, and other XtremeCloud SSO workows. If you go to the admin console Authentication left menu item and go to the Flows tab, you can view all the dened ows in the system and what actions and checks each ow requires. This section does a walk through of the browser login ow. In the left drop down list select browser to come to the screen shown below:
Browser Flow
If you hover over the tooltip (the tiny question mark) to the right of the ow selection list, this will describe what the ow is and does.
The Auth Type column is the name of authentication or action that will be executed. If an authentication is indented this means it is in a sub-ow and may or may not be executed depending on the behavior of its parent. The Requirement column is a set of radio buttons which dene whether or not the action will execute. Let’s describe what each radio button means:
Required
This authentication execution must execute successfully. If the user doesn’t have that type of
authentication mechanism configured and there is a required action associated with that
authentication type, then a required action will be attached to that account. For example, if you
switch OTP Form to Required, users that don’t have an OTP generator configured will be asked to
do so.
Optional
If the user has the authentication type configured, it will be executed. Otherwise, it will be ignored.
Disabled
If disabled, the authentication type is not executed.
Alternative
This means that at least one alternative authentication type must execute successfully at that level of
the ow.
This is better described in an example. Let’s walk through the browser authentication ow.
1. The rst authentication type is Cookie. When a user successfully logs in for the rst time, a session
cookie is set. If this cookie has already been set, then this authentication type is successful. Since the
cookie provider returned success and each execution at this level of the ow is alternative , no other
execution is executed and this results in a successful login.
2. Next the ow looks at the Kerberos execution. This authenticator is disabled by default and will be
skipped.
3. The next execution is a subow called Forms. Since this subow is marked as alternative it will not be
executed if the Cookie authentication type passed. This subow contains additional authentication
type that needs to be executed. The executions for this subow are loaded and the same processing
logic occurs
4. The rst execution in the Forms subow is the Username Password Form. This authentication type
renders the username and password page. It is marked as required so the user must enter in a valid
username and password.
5. The next execution is the OTP Form. This is marked as optional. If the user has OTP set up, then this
authentication type must run and be successful. If the user doesn’t have OTP set up, this
authentication type is ignored.
6.4. Executions
Executions can be used
Script Authenticator
A script authenticator allows to dene custom authentication logic via JavaScript. Custom authenticators. Authentication scripts must at least provide one of the following functions: authenticate(..) which is called from Authenticator#authenticate(AuthenticationFlowContext) action(..) which is called from Authenticator#action(AuthenticationFlowContext)
Custom Authenticator’s should at least provide the `authenticate(..) function. The following script javax.script.Bindings are available for convenient use within script code.
script
the ScriptModel to access script metadata
realm
the RealmModel
user
the current UserModel
session
the active XtremeCloud SSOSession
authenticationSession
the current AuthenticationSessionModel
httpRequest
the current org.jboss.resteasy.spi.HttpRequest
LOG
a org.jboss.logging.Logger scoped to ScriptBasedAuthenticator
Note that additional context information can be extracted from the context argument passed to the authenticate(context) action(context) function.
6.5. Kerberos
XtremeCloud SSO supports login with a Kerberos ticket through the SPNEGO protocol. SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is used to authenticate transparently through the web browser after the user has been authenticated when logging-in his session. For non-web cases or when ticket is not available during login, XtremeCloud SSO also supports login with Kerberos username/password.
A typical use case for web authentication is the following:
1. User logs into his desktop (Such as a Windows machine in Active Directory domain or Linux machine
with Kerberos integration enabled).
2. User then uses his browser (IE/Firefox/Chrome) to access a web application secured by XtremeCloud SSO.
3. Application redirects to XtremeCloud SSO login.
4. XtremeCloud SSO renders HTML login screen together with status 401 and HTTP header WWW-
Authenticate: Negotiate
5. In case that the browser has Kerberos ticket from desktop login, it transfers the desktop sign on
information to the XtremeCloud SSO in header Authorization: Negotiate 'spnego-token'. Otherwise it
just displays the login screen.
6. XtremeCloud SSO validates token from the browser and authenticates the user. It provisions user data from
LDAP (in case of LDAPFederationProvider with Kerberos authentication support) or let user to
update his prole and prell data (in case of KerberosFederationProvider).
7. XtremeCloud SSO returns back to the application. Communication between XtremeCloud SSO and application
happens through OpenID Connect or SAML messages. The fact that XtremeCloud SSO was authenticated
through Kerberos is hidden from the application. So XtremeCloud SSO acts as broker to Kerberos/SPNEGO
login.
AuthenticationFlowError = Java.type("org.XtremeCloud SSO.authentication.AuthenticationFlowError");
function authenticate(context) {
LOG.info(script.name + " --> trace auth for: " + user.username);
if ( user.username === "tester"
&& user.getAttribute("someAttribute")
&& user.getAttribute("someAttribute").contains("someValue")) {
context.failure(AuthenticationFlowError.INVALID_USER);
return;
}
context.success();
}
For setup there are 3 main parts:
1. Setup and conguration of Kerberos server (KDC)
2. Setup and conguration of XtremeCloud SSO server
3. Setup and conguration of client machines
6.5.1. Setup of Kerberos server
This is platform dependent. Exact steps depend on your OS and the Kerberos vendor you’re going to use. Consult Windows Active Directory, MIT Kerberos and your OS documentation for how exactly to setup and congure Kerberos server.
At least you will need to:
Add some user principals to your Kerberos database. You can also integrate your Kerberos with
LDAP, which means that user accounts will be provisioned from LDAP server.
Add service principal for "HTTP" service. For example if your XtremeCloud SSO server will be running on
http://www.mydomain.org you may need to add principal HTTP/www.mydomain.org@MYDOMAIN.ORG
assuming that MYDOMAIN.ORG will be your Kerberos realm.
For example on MIT Kerberos you can run a "kadmin" session. If you are on the same machine where
is MIT Kerberos, you can simply use the command:
Then add HTTP principal and export his key to a keytab le with the commands like:
The Keytab le /tmp/http.keytab will need to be accessible on the host where XtremeCloud SSO server will be running.
6.5.2. Setup and conguration of XtremeCloud SSO server
You need to install a kerberos client on your machine. This is also platform dependent. If you are on Fedora, Ubuntu or RHEL, you can install the package freeipa-client, which contains a Kerberos client and several other utilities. Congure the kerberos client (on linux it’s in le /etc/krb5.conf ). You need to put your Kerberos realm and at least congure the HTTP domains your server will be running on. For the example realm MYDOMAIN.ORG you may congure the domain_realm section like this:
sudo kadmin.local
addprinc -randkey HTTP/www.mydomain.org@MYDOMAIN.ORG
ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG
Next you need to export the keytab le with the HTTP principal and make sure the le is accessible to the process under which XtremeCloud SSO server is running. For production, it’s ideal if it’s readable just by this process and not by someone else. For the MIT Kerberos example above, we already exported keytab to /tmp/http.keytab. If your KDC and XtremeCloud SSO are running on same host, you have that le already available.
Enable SPNEGO Processing
XtremeCloud SSO does not have the SPNEGO protocol support turned on by default. So, you have to go to the browser ow and enable Kerberos.
Browser Flow
Switch the Kerberos requirement from disabled to either alternative or required. Alternative basically means that Kerberos is optional. If the user’s browser hasn’t been configured to work with SPNEGO/Kerberos, then XtremeCloud SSO will fall back to the regular login screens. If you set the requirement to required then all users must have Kerberos enabled for their browser.
Congure Kerberos User Storage Federation Provider
Now that the SPNEGO protocol is turned on at the authentication server, you’ll need to congure how XtremeCloud SSO interprets the Kerberos ticket. This is done through User Storage Federation. We have 2 dierent federation providers with Kerberos authentication support.
[domain_realm]
.mydomain.org = MYDOMAIN.ORG
mydomain.org = MYDOMAIN.ORG
If you want to authenticate with Kerberos backed by an LDAP server, you have to rst congure the LDAP Federation Provider. If you look at the conguration page for your LDAP provider you’ll see a Kerberos Integration section.
LDAP Kerberos Integration
Turning on the switch Allow Kerberos authentication will make XtremeCloud SSO use the Kerberos principal to lookup information about the user so that it can be imported into the XtremeCloud SSO environment.
If your Kerberos solution is not backed by an LDAP server, you have to use the Kerberos User Storage Federation Provider. Go to the User Federation left menu item and select Kerberos from the Add provider select box.
Kerberos User Storage Provider
This provider parses the Kerberos ticket for simple principal information and does a small import into the local XtremeCloud SSO database. User prole information like rst name, last name, and email are not provisioned.
6.5.3. Setup and conguration of client machines
Clients need to install kerberos client and setup krb5.conf as described above. Additionally they need to enable SPNEGO login support in their browser. See conguring Firefox for Kerberos (http://www.microhowto.info/howto/congure_refox_to_authenticate_using_spnego_and_kerberos.html) if you are
using that browser. URI .mydomain.org must be allowed in the network.negotiate-auth.trusted- uris cong option.
In a Windows domain, clients usually don’t need to congure anything special as IE is already able to participate in SPNEGO authentication for the Windows domain.
6.5.4. Example setups
For easier testing with Kerberos, we provided some example setups to test.
XtremeCloud SSO and FreeIPA docker image
Once you install docker(https://www.docker.com/), you can run docker image with FreeIPA server installed. FreeIPA provides integrated security solution with MIT Kerberos and 389 LDAP server among other things. The image provides also XtremeCloud SSO server configured with LDAP Federation provider and enabled SPNEGO/Kerberos authentication against the FreeIPA server. See details here (https://github.com/mposolda/XtremeCloud SSO-freeipa-docker/blob/master/README.md).
ApacheDS testing Kerberos server
For quick testing and unit tests, we use a very simple ApacheDS(http://directory.apache.org/apacheds/) Kerberos server. You need to build XtremeCloud SSO from sources and then run the Kerberos server with maven-exec-plugin from our testsuite. See details here (https://github.com/XtremeCloud SSO/XtremeCloud SSO/blob/master/misc/Testsuite.md#user-content-kerberos-server).
6.5.5. Credential Delegation
Kerberos 5 supports the concept of credential delegation. In this scenario, your applications may want access to the Kerberos ticket so that they can re-use it to interact with other services secured by Kerberos. Since the SPNEGO protocol is processed in the XtremeCloud SSO server, you have to propagate the GSS credential to your application within the OpenID Connect token claim or a SAML assertion attribute that is transmitted to your application from the XtremeCloud SSO server. To have this claim inserted into the token or assertion, each application will need to enable the built-in protocol mapper called gss delegation credential. This is enabled in the Mappers tab of the application’s client page. See Protocol Mappers chapter for more details.
Applications will need to deserialize the claim it receives from XtremeCloud SSO before it can use it to make GSS calls against other services. Once you deserialize the credential from the access token to the GSSCredential object, the GSSContext will need to be created with this credential passed to the method GSSManager.createContext for example like this:
We have an example, that shows this in detail. It’s in examples/kerberos in the XtremeCloud SSO example distribution or demo distribution download. You can also check the example sources directly here (https://github.com/XtremeCloud SSO/XtremeCloud SSO/tree/master/examples/kerberos).
Note that you also need to congure forwardable kerberos tickets in krb5.conf le and add support for delegated credentials to your browser.
Credential delegation has some security implications so only use it if you really need it. It’s
highly recommended to use it together with HTTPS. See for example this article
(http://www.microhowto.info/howto/congure_refox_to_authenticate_using_spnego_and_kerberos.html)
for more details.
6.5.6. トラブルシューティング
If you have issues, we recommend that you enable additional logging to debug the problem:
Enable Debug ag in admin console for Kerberos or LDAP federation providers
Enable TRACE logging for category org.XtremeCloud SSO in logging section of
standalone/configuration/standalone.xml to receive more info standalone/log/server.log
Add system properties -Dsun.security.krb5.debug=true and -
Dsun.security.spnego.debug=true ## X.509 Client Certicate User Authentication
XtremeCloud SSO supports login with a X.509 client certicate if the server is configured for mutual SSL authentication.
A typical workow is as follows:
A client sends an authentication request over SSL/TLS channel
// Obtain accessToken in your application.
XtremeCloud SSOPrincipal XtremeCloud SSOPrincipal = (XtremeCloud SSOPrincipal) servletReq.getUserPrincipal();
AccessToken accessToken = XtremeCloud SSOPrincipal.getXtremeCloud SSOSecurityContext().getToken();
// Retrieve kerberos credential from accessToken and deserialize it
String serializedGssCredential = (String) accessToken.getOtherClaims().
get(org.XtremeCloud SSO.common.constants.KerberosConstants.GSS_DELEGATION_CREDENTIAL);
GSSCredential deserializedGssCredential =
org.XtremeCloud SSO.common.util.KerberosSerializationUtils.
deserializeCredential(serializedGssCredential);
// Create GSSContext to call other kerberos-secured services
GSSContext context = gssManager.createContext(serviceName, krb5Oid,
deserializedGssCredential, GSSContext.DEFAULT_LIFETIME);
During SSL/TLS handshake, the server and the client exchange their x.509/v3 certicates
The container (wildy) validates the certicate PKIX path and the certicate expiration
The x.509 client certicate authenticator validates the client certicate as follows:
Optionally checks the certicate revocation status using CRL and/or CRL Distribution Points
Optionally checks the Certicate revocation status using OCSP (Online Certicate Status Protocol)
Optinally validates whether the key usage in the certicate matches the expected key usage
Optionally validates whether the extended key usage in the certicate matches the expected
extended key usage
If any of the above checks fails, the x.509 authentication fails
Otherwise, the authenticator extracts the certicate identity and maps it to an existing user
Once the certicate is mapped to an existing user, the behavior diverges depending on the
authentication ow:
In the Browser Flow, the server prompts the user to conrm identity or to ignore it and instead
sign in with username/password
In the case of the Direct Grant Flow, the server signs in the user
6.6. 機能
6.6.1. Supported Certicate Identity Sources
Match SubjectDN using regular expression
X500 Subject’s e-mail attribute
X500 Subject’s Common Name attribute
Match IssuerDN using regular expression
X500 Issuer’s e-mail attribute
X500 Issuer’s Common Name attribute
Certicate Serial Number
6.6.2. Regular Expressions
The certicate identity can be extracted from either Subject DN or Issuer DN using a regular expression as a lter. For example, the regular expression below will match the e-mail attribute:
emailAddress=(.*?)(?:,|$)
The regular expression ltering is applicable only if the Identity Source is set to either Match SubjectDN using regular expression or Match IssuerDN using regular expression.
6.6.3. Mapping certicate identity to an existing user
The certicate identity mapping can be configured to map the extracted user identity to an existing user’s username or e-mail or to a custom attribute which value matches the certicate identity. For example, setting the Identity source to Subject’s e-mail and User mapping method to Username or email will have the X.509 client certicate authenticator use the e-mail attribute in the certicate’s Subject DN as a search criteria to look up an existing user by username or by e-mail.
Please notice that if we disable Login with email at realm settings, the same rules will
be applied to certicate authentication. In other words, users won’t be able to log in
using e-mail attribute.
6.6.4. Other Features: Extended Certicate Validation
Revocation status checking using CRL
Revocation status checking using CRL/Distribution Point
Revocation status checking using OCSP/Responder URI
Certicate KeyUsage validation
Certicate ExtendedKeyUsage validation
6.7. Enable X.509 Client Certicate User Authentication
The following sections describe how to congure Wildy/Undertow and the XtremeCloud SSO Server to enable X.509 client certicate authentication.
6.7.1. Enable mutual SSL in WildFly
See Enable SSL(https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL) and SSL (https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D) for the instructions how to enable SSL in Wildy.
Open $XtremeCloud SSO_HOME/standalone/conguration/standalone.xml and add a new realm:
ssl/keystore
The ssl element contains the keystore element that denes how to load the server public key pair
from a JKS keystore
ssl/keystore/path
A path to a JKS keystore
ssl/keystore/relative-to
Denes a path the keystore path is relative to
ssl/keystore/keystore-password
The password to open the keystore
ssl/keystore/alias (optional)
The alias of the entry in the keystore. Set it if the keystore contains multiple entries
ssl/keystore/key-password (optional)
The private key password, if dierent from the keystore password.
authentication/truststore
Denes how to load a trust store to verify the certicate presented by the remote side of the
inbound/outgoing connection. Typically, the truststore contains a collection of trusted CA certicates.
authentication/truststore/path
A path to a JKS keystore that contains the certicates of the trusted CAs (certicate authorities)
authentication/truststore/relative-to
<security-realms>
<security-realm name="ssl-realm">
<server-identities>
<ssl>
<keystore path="servercert.jks"
relative-to="jboss.server.config.dir"
keystore-password="servercert password"/>
</ssl>
</server-identities>
<authentication>
<truststore path="truststore.jks"
relative-to="jboss.server.config.dir"
keystore-password="truststore password"/>
</authentication>
</security-realm>
</security-realms>
Denes a path the truststore path is relative to
authentication/truststore/keystore-password
The password to open the truststore
6.7.2. Enable https listener
See HTTPS Listener(https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-HTTPSlistener) for the instructions how to enable HTTPS in Wildy.
Add the <https-listener> element as shown below:
https-listener/security-realm
The value must match the name of the realm from the previous section
https-listener/verify-client
If set to REQUESTED, the server will optionally ask for a client certicate. Setting the attribute to
REQUIRED will have the server to refuse inbound connections if no client certicate has been
provided.
6.8. Adding X.509 Client Certicate Authentication to a Browser Flow
Select a realm, click on Authentication link, select the "Browser" ow
Make a copy of the buit-in "Browser" ow. You may want to give the new ow a distinctive name, i.e.
"X.509 Browser"
Using the drop down, select the copied ow, and click on "Add Execution"
Select "X509/Validate User Form" using the drop down and click on "Save"
<subsystem xmlns="urn:jboss:domain:undertow:3.1">
....
<server name="default-server">
<https-listener name="default"
socket-binding="https"
security-realm="ssl-realm"
verify-client="REQUESTED"/>
</server>
</subsystem>
XML
Using the up/down arrows, change the order of the “X509/Validate Username Form” by moving it above the “Browser Forms” execution, and set the requirement to “ALTERNATIVE”
Select the “Bindings” tab, nd the drop down for “Browser Flow”. Select the newly created X509 browser ow from the drop down and click on “Save”.
6.8.1. Conguring X.509 Client Certicate Authentication
User Identity Source
Denes how to extract the user identity from a client certicate.
A regular expression (optional)
Denes a regular expression to use as a lter to extract the certicate identity. The regular expression
must contain a single group.
User Mapping Method
Denes how to match the certicate identity to an existing user. Username or e-mail will search for an
existing user by username or e-mail. Custom Attribute Mapper will search for an existing user with a
custom attribute which value matches the certicate identity. The name of the custom attribute is
congurable.
A name of user attribute (optional)
A custom attribute which value will be matched against the certicate identity.
CRL Checking Enabled (optional)
Denes whether to check the revocation status of the certicate using Certicate Revocation List.
Enable CRL Distribution Point to check certificate revocation status (optional)
Denes whether to use CDP to check the certicate revocation status. Most PKI authorities include
CDP in their certicates.
CRL file path (optional)
Denes a path to a le that contains a CRL list. The value must be a path to a valid le if CRL Checking
Enabled option is turned on.
OCSP Checking Enabled (optional)
Denes whether to check the certicate revocation status using Online Certicate Status Protocol.
OCSP Responder URI (optional)
Allows to override a value of the OCSP responder URI in the certicate.
Validate Key Usage (optional)
Veries whether the certicate’s KeyUsage extension bits are set. For example,
"digitalSignature,KeyEncipherment" will verify if bits 0 and 2 in the KeyUsage extension are asserted.
Leave the parameter empty to disable the Key Usage validaion. See RFC5280, Section-4.2.1.3
(https://tools.ietf.org/html/rfc5280#section-4.2.1.3). The server will raise an error only when agged as
critical by the issuing CA and there is a key usage extension mismatch.
Validate Extended Key Usage (optional)
Veries one or more purposes as dened in the Extended Key Usage extension. See RFC5280, Section-
4.2.1.12(https://tools.ietf.org/html/rfc5280#section-4.2.1.12). Leave the parameter empty to disable the
Extended Key Usage validation. The server will raise an error only when agged as critical by the
issuing CA and there is a key usage extension mismatch.
Bypass identity confirmation
If set, X.509 client certicate authentication will not prompt the user to conrm the certicate identity
and will automatiocally sign in the user upon successful authentication.
6.9. Adding X.509 Client Certicate Authentication to a Direct Grant Flow
Using XtremeCloud SSO admin console, click on "Authentication" and select the "Direct Grant" ow,
Make a copy of the build-in “Direct Grant” ow. You may want to give the new ow a distinctive name, i.e. “X509 Direct Grant”,
Delete “Validate Username” and “Password” authenticators,
Click on “Execution” and add “X509/Validate Username” and click on “Save” to add the execution step to the parent ow.
Change the Requirement to REQUIRED.
Set up the x509 authentication conguration by following the steps described earlier in the x.509 Browser Flow section.
Select the “Bindings” tab, nd the drop down for “Direct Grant Flow”. Select the newly created X509 direct grant ow from the drop down and click on “Save”.
6.10. トラブルシューティング
6.10.1. Direct Grant authentication with X.509
The following template can be used to request a token using the Resource Owner Password Credentials Grant:
[host][:port]
The host and the port number of a remote XtremeCloud SSO server that has been configured to allow users
authenticate with x.509 client certicates using the Direct Grant Flow.
CLIENT_ID
A client id.
CLIENT_SECRET
For condential clients, a client secret; otherwise, leave it empty.
client_cert.crt
A public key certicate that will be used to verify the identity of the client in mutual SSL authentication.
The certicate should be in PEM format.
client_cert.key
A private key in the public key pair. Also expected in PEM format.
7. SSOプロトコル
この章では、認証プロトコルと、XtremeCloud SSO認証サーバーとセキュア保護されるアプリケーションがこれらの プロトコルで相互作用する仕組みについて簡単に説明します。
7.1. Open ID Connect
Open ID Connect(http://openid.net/connect/) (OIDC) is an authentication protocol that is an extension of OAuth 2.0(https://tools.ietf.org/html/rfc6749). While OAuth 2.0 is only a framework for building authorization protocols and is mainly incomplete, OIDC is a full-edged authentication and authorization protocol.
$ curl https://[host][:port]/auth/realms/master/protocol/openid-connect/token \
--insecure \
--data "grant_type=password&scope=openid
profile&username=&password=&client_id=CLIENT_ID&client_secret=CLIENT_SECRET" \
-E /path/to/client_cert.crt \
--key /path/to/client_cert.key
OIDC also makes heavy use of the Json Web Token(https://jwt.io) (JWT) set of standards. These standards dene an identity token JSON format and ways to digitally sign and encrypt that data in a compact and web-friendly way.
There are really two types of use cases when using OIDC. The rst is an application that asks the XtremeCloud SSO server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token. The identity token contains information about the user such as username, email, and other prole information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks XtremeCloud SSO to obtain an access token it can use to invoke on other remote services on behalf of the user. XtremeCloud SSO authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token , veries the signature of the token, then decides based on access information within the token whether or not to process the request.
7.1.1. OIDC Auth Flows
OIDC has dierent ways for a client or application to authenticate a user and receive an identity and access token. Which path you use depends greatly on the type of application or client requesting access. All of these ows are described in the OIDC and OAuth 2.0 specications so only a brief overview will be provided here.
Authorization Code Flow
This is a browser-based protocol and it is what we recommend you use to authenticate and authorize browser-based applications. It makes heavy use of browser redirects to obtain an identity and access token. Here’s a brief summary:
1. Browser visits application. The application notices the user is not logged in, so it redirects the
browser to XtremeCloud SSO to be authenticated. The application passes along a callback URL (a redirect
URL) as a query parameter in this browser redirect that XtremeCloud SSO will use when it nishes
authentication.
2. XtremeCloud SSO authenticates the user and creates a one-time, very short lived, temporary code. XtremeCloud SSO
redirects back to the application using the callback URL provided earlier and additionally adds the
temporary code as a query parameter in the callback URL.
3. The application extracts the temporary code and makes a background out of band REST invocation
to XtremeCloud SSO to exchange the code for an identity , access and refresh token. Once this temporary code
has been used once to obtain the tokens, it can never be used again. This prevents potential replay
attacks.
It is important to note that access tokens are usually short lived and often expired after only minutes. The additional refresh token that was transmitted by the login protocol allows the application to obtain a new access token after it expires. This refresh protocol is important in the situation of a compromised system. If access tokens are short lived, the whole system is only vulnerable to a stolen token for the lifetime of the access token. Future refresh token requests will fail if an admin has revoked access. This makes things more secure and more scalable.
Another important aspect of this ow is the concept of a public vs. a condential client. Condential clients are required to provide a client secret when they exchange the temporary codes for tokens. Public clients are not required to provide this client secret. Public clients are perfectly ne so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the client. HTML5/JavaScript clients always have to be public clients because there is no way to transmit the client secret to them in a secure manner. Again, this is ok so long as you use HTTPS and strictly enforce redirect URI registration. This guide goes more detail into this in the Managing Clients chapter.
Implicit Flow
This is a browser-based protocol that is similar to Authorization Code Flow except there are fewer requests and no refresh tokens involved. We do not recommend this ow as there remains the possibility of access tokens being leaked in the browser history as tokens are transmitted via redirect URIs (see below). Also, since this ow doesn’t provide the client with a refresh token, access tokens would either have to be long-lived or users would have to re-authenticate when they expired. This ow is supported because it is in the OIDC and OAuth 2.0 specication. Here’s a brief summary of the protocol:
1. Browser visits application. The application notices the user is not logged in, so it redirects the
browser to XtremeCloud SSO to be authenticated. The application passes along a callback URL (a redirect
URL) as a query parameter in this browser redirect that XtremeCloud SSO will use when it nishes
authentication.
2. XtremeCloud SSO authenticates the user and creates an identity and access token. XtremeCloud SSO 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.
3. The application extracts the identity and access tokens from the callback URL.
Resource Owner Password Credentials Grant (Direct Access Grants)
This is referred to in the Admin Console as Direct Access Grants. This is used by REST clients that want to obtain a token on behalf of a user. It is one HTTP POST request that contains the credentials of the user as well as the id of the client and the client’s secret (if it is a condential client). The user’s credentials are sent within form parameters. The HTTP response contains identity , access , and refresh tokens.
Client Credentials Grant
This is also used by REST clients, but instead of obtaining a token that works on behalf of an external user, a token is created based on the metadata and permissions of a service account that is associated with the client. More info together with example is in Service Accounts chapter.
7.1.2. XtremeCloud SSO Server OIDC URI Endpoints
Here’s a list of OIDC endpoints that the XtremeCloud SSO publishes. These URLs are useful if you are using a non- XtremeCloud SSO client adapter to talk OIDC with the auth server. These are all relative URLs and the root of the URL being the HTTP(S) protocol, hostname, and usually path prexed with /auth : i.e. https://localhost:8080/auth
/realms/{realm-name}/protocol/openid-connect/token
This is the URL endpoint for obtaining a temporary code in the Authorization Code Flow or for
obtaining tokens via the Implicit Flow, Direct Grants, or Client Grants.
/realms/{realm-name}/protocol/openid-connect/auth
This is the URL endpoint for the Authorization Code Flow to turn a temporary code into a token.
/realms/{realm-name}/protocol/openid-connect/logout
This is the URL endpoint for performing logouts.
/realms/{realm-name}/protocol/openid-connect/userinfo
This is the URL endpoint for the User Info service described in the OIDC specication.
In all of these replace {realm-name} with the name of the realm.
7.2. SAML
SAML 2.0(http://saml.xml.org/saml-specications) is a similar specication to OIDC but a lot older and more mature. It has its roots in SOAP and the plethora of WS-* specications 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 is really two types of use cases when using SAML. The rst is an application that asks the XtremeCloud SSO server to authenticate a user for them. After a successful login, the application will receive an XML document that contains something called a SAML assertion that specify various attributes about the user. This XML document is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks XtremeCloud SSO to obtain an SAML assertion it can use to invoke on other remote services on behalf of the user.
7.2.1. SAML Bindings
SAML denes a few dierent 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 XtremeCloud SSO only supports those three.
Redirect Binding
The Redirect Binding uses a series of browser redirect URIs to exchange information. This is a rough overview of how it works.
1. The user visits the application and the application nds 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 XtremeCloud SSO server. Depending on your settings, the application may also digitally sign
this XML document and also stu this signature as a query param in the redirect URI to XtremeCloud SSO.
This signature is used to validate the client that sent this request.
2. The browser is redirected to XtremeCloud SSO. The server extracts the XML auth request document and
veries the digital signature if required. The user then has to enter in their credentials to be
authenticated.
3. After authentication, the server generates an XML authentication response document. This
document contains a SAML assertion that holds metadata about the user like name, address, email,
and any role mappings the user might have. This document is almost always digitally signed using
XML signatures, and may also be encrypted.
4. 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.
5. The application receives the redirect URI and extracts the XML document and veries 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.
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 XtremeCloud SSO 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 stu, but it is a pretty clever trick.
ECP
ECP stands for “Enhanced Client or Proxy”, a SAML v.2.0 prole 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. XtremeCloud SSO Server SAML URI Endpoints
XtremeCloud SSO 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 対 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, we recommend using OIDC in XtremeCloud SSO.
SAML tends to be slightly more verbose than OIDC.
Beyond verbosity of exchanged data, if you compare the specications you’ll nd that OIDC was designed to work with the web while SAML was retrotted 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 nd several nice features that make implementing security in your web applications easier. For example, check out the iframe trick(http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotication) that the specication uses to easily determine if a user is still logged in or not.
SAML also has use. Looking at the evolution of the specication of OIDC, we can see that many functions implemented by SAML for many years are also implemented in OIDC. SAML is often chosen more than OIDC because of the recognition that SAML is more mature than OIDC and the existence of existing applications secured by SAML.
7.4. Docker Registry v2 Authentication
Docker authentication is disabled by default. To enable it, please refer to Proles
(http://www.XtremeCloud SSO.org/docs/3.4/server_installation/#_proles).
Docker Registry V2 Authentciation(https://docs.docker.com/registry/spec/auth/) is an OIDC-Like protocol used to authenticate users against a Docker registry. XtremeCloud SSO’s implementation of this protocol allows for a XtremeCloud SSO authentication server to be used by a Docker client to authenticate against a registry.
While this protocol uses fairly standard token and signature mechanisms, it has a few wrinkles that prevent it from being treated as a true OIDC implementation. The largest deviations include a very specic JSON format for requests and responses as well as the ability to understand how to map repository names and permissions to the OAuth scope mechanism.
7.4.1. Docker Auth Flow
The Docker API documentation(https://docs.docker.com/registry/spec/auth/token/) best describes and illustrates this process, however a brief summary will be given below from the perspective of they XtremeCloud SSO authentication server.
This ow assumes that a docker login command has already been performed
The ow begins when the Docker client requests a resource from the Docker registry. If the resource
is protected and no auth token is present in the request, the Docker registry server will respond to
the client with a 401 + some information on required permissions and where to nd the
authorization server.
The Docker client will construct an authentication request based on the 401 response from the
Docker registry. The client will then use the locally cached credentials (from a previously run docker
login command) as part of a HTTP Basic Authentication(https://tools.ietf.org/html/rfc2617) request to
the XtremeCloud SSO authentication server.
The XtremeCloud SSO authentication server will attempt to authenticate the user and return a JSON body
containing an OAuth-style Bearer token.
The Docker client will get the bearer token from the JSON response and use it in the Authorization
header to request the protected resource.
When the Docker registry recieves the new request for the protected resource with the token from
the XtremeCloud SSO server, the registry validates the token and grants access to the requested resource (if
appropriate).
7.4.2. XtremeCloud SSO Docker Registry v2 Authentication Server URI Endpoints
XtremeCloud SSO really only has one endpoint for all Docker auth v2 requests.
http(s)://authserver.host/auth/realms/{realm-name}/protocol/docker-v2
8. Managing Clients
Clients are entities that can request authentication of a user. Clients come in two forms. The rst type of client is an application that wants to participate in single-sign-on. These clients just want XtremeCloud SSO 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 conguring clients and various ways to do it.
8.1. OIDC Clients
OpenID Connect is the preferred protocol to secure applications. It was designed from the ground up to be web friendly and work best with HTML5/JavaScript applications.
To create an OIDC client go to the Clients left menu item. On this page you’ll see a Create button on the right.
クライアント
This will bring you to the Add Client page.
クライアントの追加
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 XtremeCloud SSO database to identify the client. Next select openid-connect in the Client Protocol drop down box. Ignore the Client Template listbox for now, we’ll go over that later in this chapter. Finally enter in the base URL of your application in the Root URL eld and click Save. This will create the client and bring you to the client Settings tab.
Client Settings
Let’s walk through each conguration item on this page.
Client ID
This species an alpha-numeric string that will be used as the client identier for OIDC requests.
Name
This is the display name for the client whenever it is displayed in a XtremeCloud SSO UI screen. You can localize the value of this eld by setting up a replacement string value i.e. ${myapp}. See the Server Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for more information.
Description
This species the description of the client. This can also be localized.
Enabled
If this is turned o, the client will not be allowed to request authentication.
Consent Required
If this is on, then users will get a consent page which asks the user if they grant access to that application. It will also display the metadata that the client is interested in so that the user knows exactly what information the client is getting access to. If you’ve ever done a social login to Google, you’ll often see a similar page. XtremeCloud SSO provides the same functionality.
Access Type
This denes the type of the OIDC client.
condential
Condential access type is for server-side clients that need to perform a browser login and require a
client secret when they turn an access code into an access token, (see Access Token Request
(https://tools.ietf.org/html/rfc6749#section-4.1.3) in the OAuth 2.0 spec for more details). This type should
be used for server-side applications.
public
Public access type is for client-side clients that need to perform a browser login. With a client-side
application there is no way to keep a secret safe. Instead it is very important to restrict access by
conguring 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 XtremeCloud SSO uses any configured relative URLs, this value is prepended to them.
Valid Redirect URIs
This is a required eld. Enter in a URL pattern 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! Wildcards (*) are only allowed at the end of a URI, i.e. [http://host.com/](http://host.com/)
You should take extra precautions when registering valid redirect URI patterns. If you make them too general you are vulnerable to attacks. See Threat Model Mitigation chapter for more information.
Base URL
If XtremeCloud SSO needs to link to the client, this URL is used.
Standard Flow Enabled
If this is on, clients are allowed to use the OIDC Authorization Code Flow.
Implicit Flow Enabled
If this is on, clients are allowed to use the OIDC Implicit Flow.
Direct Grants Enabled
If this is on, clients are allowed to use the OIDC Direct Grants.
Admin URL
For XtremeCloud SSO specic client adapters, this is the callback endpoint for the client. The XtremeCloud SSO server will use this URI to make callbacks like pushing revocation policies, performing backchannel logout, and other administrative operations. For XtremeCloud SSO servlet adapters, this can be the root URL of the servlet application. For more information see Securing Applications and Services Guide (http://www.XtremeCloud SSO.org/docs/3.4/securing_apps/).
Web Origins
This option centers around CORS(http://www.w3.org/TR/cors/) which stands for Cross-Origin Resource Sharing. If browser JavaScript tries to make an AJAX HTTP request to a server whose domain is dierent from the one the JavaScript code came from, then the request must use CORS. The server must handle CORS requests in a special way, otherwise the browser will not display or allow the request to be processed. This protocol exists to protect against XSS, CSRF and other JavaScript-based attacks.
XtremeCloud SSO has support for validated CORS requests. The way it works is that the domains listed in the Web Origins setting for the client are embedded within the access token sent to the client application. The client application can then use this information to decide whether or not to allow a CORS request to be
invoked on it. This is an extension to the OIDC protocol so only XtremeCloud SSO client adapters support this feature. See Securing Applications and Services Guide(http://www.XtremeCloud SSO.org/docs/3.4/securing_apps/) for more information.
To ll 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. Condential 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 congure the client’s credentials.
Credentials Tab
The Client Authenticator list box species the type of credential you are going to use for your condential 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) instead of a secret.
Signed JWT
When choosing this credential type you will have to also generate a private key and certicate for the client. The private key will be used to sign the JWT, while the certicate 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, XtremeCloud SSO will store the certicate, and you’ll need to download the private key and certicate 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 certicate.
Import Certicate
There are multiple formats you can import from, just choose the archive format you have the certicate stored in, select the le, and click the Import button.
Finally note that you don’t even need to import certicate if you choose to Use JWKS URL. In that case, you can provide the URL where client publishes it’s public key in JWK (https://self-issued.info/docs/draft-ietf-jose-json-web-key.html) format. This is exible because when client changes it’s keys, XtremeCloud SSO will automatically download them without need to re-import anything on XtremeCloud SSO side.
If you use client secured by XtremeCloud SSO adapter, you can congure the JWKS URL like https://myhost.com/myapp/k_jwks assuming that https://myhost.com/myapp is the root URL of your client application. See Server Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for additional details.
For the performance purposes, XtremeCloud SSO 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.
8.2. 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 speciation under Client Credentials Grant. To use this feature you must set the Access Type of your client to confidential. When you do this, the Service Accounts Enabled switch will appear. You need to turn on this switch. Also make sure that you have configured your client credentials.
To use it you must have registered a valid confidential Client and you need to check the switch Service Accounts Enabled in XtremeCloud SSO admin console for this client. In tab Service Account Roles you can congure the roles available to the service account retrieved on behalf of this client. Don’t forget that you need those roles to be available in Scopes of this client as well (unless you have Full Scope Allowed on). As in normal login, roles from access token are the intersection of scopes and the service account roles.
The REST URL to invoke on is /auth/realms/{realm-name}/protocol/openid-connect/token. Invoking on this URL is a POST request and requires you to post the client credentials. By default, client credentials are represented by clientId and clientSecret of the client in Authorization: Basic header, but you can also authenticate the client with a signed JWT assertion or any other custom mechanism for client authentication. You also need to use the parameter grant_type=client_credentials as per the OAuth2 specication.
For example the POST invocation to retrieve a service account can look like this:
The response would be this standard JSON document(https://tools.ietf.org/html/rfc6749#section-4.4.3) from the OAuth 2.0 specication.
The retrieved access token can be refreshed or logged out by an out-of-bound request.
8.3. SAML Clients
XtremeCloud SSO supports SAML 2.0 for registered applications. Both POST and Redirect bindings are supported. You can choose to require client signature validation and can have the server sign and/or encrypt responses as well.
To create a SAML client go to the Clients left menu item. On this page you’ll see a Create button on the right.
クライアント
POST /auth/realms/demo/protocol/openid-connect/token
Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":60,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"refresh_expires_in":600,
"id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"not-before-policy":0,
"session_state":"234234-234234-234234"
}
This will bring you to the Add Client page.
クライアントの追加
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. Ignore the Client Template listbox for now, we’ll go over that later in this chapter. Finally enter in the Client SAML Endpoint URL. Enter the URL you want the XtremeCloud SSO server to send SAML requests and responses to. Usually applications have only one URL for processing SAML requests. If your application has dierent URLs for its bindings, don’t worry, you can x this in the Settings tab of the client. Click Save. This will create the client and bring you to the client Settings tab.
Client Settings
Client ID
This value must match the issuer value sent with AuthNRequests. XtremeCloud SSO will pull the issuer from
the Authn SAML request and match it to a client by this value.
name
This is the display name for the client whenever it is displayed in a XtremeCloud SSO UI screen. You can localize
the value of this eld by setting up a replacement string value i.e. ${myapp}. See the Server Developer
Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for more information.
Description
This species the description of the client. This can also be localized.
Enabled
If this is turned o, the client will not be allowed to request authentication.
Consent Required
If this is on, then users will get a consent page which asks the user if they grant access to that
application. It will also display the metadata that the client is interested in so that the user knows
exactly what information the client is getting access to. If you’ve ever done a social login to Google,
you’ll often see a similar page. XtremeCloud SSO provides the same functionality.
Include AuthnStatement
SAML login responses may specify the authentication method used (password, etc.) as well as a
timestamp of the login. Setting this to on will include that statement in the response document.
Sign Documents
When turned on, XtremeCloud SSO will sign the document using the realm’s private key.
Optimize REDIRECT signing key lookup
When turned on, the SAML protocol messages will include XtremeCloud SSO native extension that contains a
hint with signing key ID. When the SP understands this extension, it can use it for signature validation
instead of attempting to validate signature with all known keys. This option only applies to REDIRECT
bindings where the signature is transferred in query parameters where there is no place with this
information in the signature information (contrary to POST binding messages where key ID is always
included in document signature). Currently this is relevant to situations where both IDP and SP are
provided by XtremeCloud SSO server and adapter. This option is only relevant when Sign Documents is
switched on.
Sign Assertions
The Sign Documents switch signs the whole document. With this setting the assertion is also signed
and embedded within the SAML XML Auth response.
Signature Algorithm
Choose between a variety of algorithms for signing SAML documents.
SAML Signature Key Name
Signed SAML documents sent via POST binding contain identication of signing key in KeyName
element. This by default contains XtremeCloud SSO key ID. However various vendors might expect a dierent
key name or no key name at all. This switch controls whether KeyName contains key ID (option
KEY_ID), subject from certicate corresponding to the realm key (option CERT_SUBJECT - expected
for instance by Microsoft Active Directory Federation Services), or that the key name hint is
completely omitted from the SAML message (option NONE).
Canonicalization Method
Canonicalization method for XML signatures.
Encrypt Assertions
Encrypt assertions in SAML documents with the realm’s private key. The AES algorithm is used with a
key size of 128 bits.
Client Signature Required
Expect that documents coming from a client are signed. XtremeCloud SSO will validate this signature using the
client public key or cert set up in the SAML Keys tab.
Force POST Binding
By default, XtremeCloud SSO will respond using the initial SAML binding of the original request. By turning on
this switch, you will force XtremeCloud SSO to always respond using the SAML POST Binding even if the original
request was the Redirect binding.
Front Channel Logout
If true, this application requires a browser redirect to be able to perform a logout. For example, the
application may require a cookie to be reset which could only be done via a redirect. If this switch is
false, then XtremeCloud SSO will invoke a background SAML request to logout the application.
Force Name ID Format
If the request has a name ID policy, ignore it and used the value configured in the admin console
under Name ID Format
Name ID Format
Name ID Format for the subject. If no name ID policy is specied in the request or if the Force Name
ID Format attribute is true, this value is used. Properties used for each of the respective formats are
dened below.
Root URL
If XtremeCloud SSO uses any configured relative URLs, this value is prepended to them.
Valid Redirect URIs
This is an optional eld. Enter in a URL pattern 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! Wildcards (\*) are only
allowed at the end of of a URI, i.e. http://host.com/*. This eld is used when the exact SAML endpoints
are not registered and XtremeCloud SSO is pull the Assertion Consumer URL from the request.
Base URL
If XtremeCloud SSO needs to link to the client, this URL would be used.
Master SAML Processing URL
This URL will be used for all SAML requests and the response will be directed to the SP. It will be used
as the Assertion Consumer Service URL and the Single Logout Service URL. If a login request contains
the Assertion Consumer Service URL, that will take precedence, but this URL must be valided by a
registered Valid Redirect URI pattern
Assertion Consumer Service POST Binding URL
POST Binding URL for the Assertion Consumer Service.
Assertion Consumer Service Redirect Binding URL
Redirect Binding URL for the Assertion Consumer Service.
Logout Service POST Binding URL
POST Binding URL for the Logout Service.
Logout Service Redirect Binding URL
Redirect Binding URL for the Logout Service.
8.3.1. IDP Initiated Login
IDP Initiated Login is a feature that allows you to set up an endpoint on the XtremeCloud SSO server that will log you into a specic application/client. In the Settings tab for your client, you need to specify the IDP Initiated SSO URL Name. This is a simple string with no whitespace in it. After this you can reference your client at the following URL: root/auth/realms/{realm}/protocol/saml/clients/{url-name}
If your client requires a special relay state, you can also congure this on the Settings tab in the IDP Initiated SSO Relay State eld. Alternatively, browsers can specify the relay state in a RelayState query parameter, i.e. root/auth/realms/{realm}/protocol/saml/clients/{url-name}? RelayState=thestate.
When using identity brokering, it is possible to set up an IDP Initiated Login for a client from an external IDP. The actual client is set up for IDP Initiated Login at broker IDP as described above. The external IDP has to set up the client for application IDP Initiated Login that will point to a special URL pointing to the broker and representing IDP Initiated Login endpoint for a selected client at the brokering IDP. This means that in client settings at the external IDP:
IDP Initiated SSO URL Name is set to a name that will be published as IDP Initiated Login initial
point,
Assertion Consumer Service POST Binding URL in the Fine Grain SAML Endpoint
Configuration section has to be set to the following URL: broker-root/auth/realms/{broker-
realm}/broker/{idp-name}/endpoint/clients/{client-id}, where:
broker-root is base broker URL
broker-realm is name of the realm at broker where external IDP is declared
idp-name is name of the external IDP at broker
client-id is the value of IDP Initiated SSO URL Name attribute of the SAML client dened at
broker. It is this client, which will be made available for IDP Initiated Login from the external IDP.
Please note that you can import basic client settings from the brokering IDP into client settings of the external IDP - just use SP Descriptor available from the settings of the identity provider in the brokering IDP, and add clients/client-id to the endpoint URL.
8.3.2. SAMLエンティティ記述子
Instead of manually registering a SAML 2.0 client, you can import it via a standard SAML Entity Descriptor XML le. There is an Import option on the Add Client page.
クライアントの追加
Click the Select File button and load your entity descriptor le. You should review all the information there to make sure everything is set up correctly.
Some SAML client adapters like mod-auth-mellon need the XML Entity Descriptor for the IDP. You can obtain this by going to this public URL: root/auth/realms/{realm}/protocol/saml/descriptor
8.4. Client Links
For scenarios where one wants to link from one client to another, XtremeCloud SSO provides a special redirect endpoint: /realms/realm_name/clients/{client-id}/redirect.
If a client accesses this endpoint via an HTTP GET request, XtremeCloud SSO returns the configured base URL for the provided Client and Realm in the form of an HTTP 307 (Temporary Redirect) via the response’s Location header.
Thus, a client only needs to know the Realm name and the Client ID in order to link to them. This indirection helps avoid hard-coding client base URLs.
As an example, given the realm master and the client-id account:
Would temporarily redirect to: http://host:port/auth/realms/master/account
8.5. OIDC Token and SAML Assertion Mappings
Applications that receive ID Tokens, Access Tokens, or SAML assertions may need or want dierent user metadata and roles. XtremeCloud SSO allows you to dene what exactly is transferred. You can hardcode roles, claims and custom attributes. You can pull user metadata into a token or assertion. You can rename roles. Basically you have a lot of control of what exactly goes back to the client.
Within the Admin Console, if you go to an application you’ve registered, you’ll see a Mappers tab. Here’s one for an OIDC based client.
Mappers Tab
Each client has several built-in mappers that are created for it by default. They map things like, for example, email address to a specic claim in the identity and access token. Their function should each be self explanatory from their name. There are additional pre-configured mappers that are not attached to the client that you can add by clicking the Add Builtin button.
http://host:port/auth/realms/master/clients/account/redirect
Each mapper has common settings as well as additional ones depending on which type of mapper you are adding. Click the Edit button next to one of the mappers in the list to get to the cong screen.
Mapper Cong
The best way to learn about a cong option is to hover over its tooltip. There are a few cong options that are common to all mappers:
Consent Required
If your client requires consent, this mapper will be displayed on the consent screen shown to the
user.
Consent Text
If your client requires consent and the Consent switch is on, this is the text that will be displayed by
the user. The value for this text is localizable by specifying a substitution variable with ${var-name}
strings. The localized value is then configured within property les in your theme. See the Server
Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for more information on
localization.
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 ddling with the Add to ID token and Add to access token switches.
Finally, you can also add other mapper types. If you go back to the Mappers tab, click the Create button.
Add Mapper
Pick a Mapper Type from the list box. If you hover over the tooltip, you’ll see a description of what that mapper type does. Dierent cong parameters will appear for dierent mapper types.
8.6. Generating Client Adapter Cong
The XtremeCloud SSO can pre-generate conguration les 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 conguration for.
Select the Format Option you want conguration generated for. All XtremeCloud SSO 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 les.
8.7. Client Templates
If you have a lot of applications you need to secure and register within your organization it can become quite tedious to congure the protocol mappers and scope for each of these clients. XtremeCloud SSO allows you to dene shared client conguration in an entity called a client template.
To create a client template, go to the Client Templates left menu item. This initial screen shows you a list of currently dened templates.
To create a template click the Create button. This brings you to a simple screen in which you name the template and hit save. A client template will have similar tabs to regular clients. You’ll be able to dene protocol mappers and scope which can be inherited by other clients.
Having a client inherit from a template is as simple as choosing the template from the Client Template drop down list on either the Add Client or client Settings tab. You will see the Mappers and Scope tabs get additional switches which allow you to turn on or o inheriting from the parent template.
Future versions of client templating may get more inheritable conguration options, but for now, that’s all there is to talk about.
9. Roles
Roles identify a type or category of user. Admin, user, manager, and employee are all typical roles that may exist in an organization. Applications often assign access and permissions to specic roles rather than individual users as dealing with users can be too ne grained and hard to manage. For
example, the Admin Console has specic roles which give permission to users to access parts of the Admin Console UI and perform certain actions. There is a global namespace for roles and each client also has its own dedicated namespace where roles can be dened.
9.1. Realm Roles
Realm-level roles are a global namespace to dene your roles. You can see the list of built-in and created roles by clicking the Roles left menu item.
To create a role, click Add Role on this page, enter in the name and description of the role, and click Save.
Add Role
The value for the description eld is localizable by specifying a substitution variable with ${var- name} strings. The localized value is then configured within property les in your theme. See the Server Developer Guide(http://www.XtremeCloud SSO.org/docs/3.4/server_development/) for more information on localization. If a client requires user consent , this description string is displayed on the consent page for the user.
If the client has to explicitly request for a realm role, set Scope Param Required to true. The role then has to be specied using the scope parameter when requesting a token. Multiple realm roles are separated by space:
scope=admin user
9.2. Client Roles
Client roles are basically a namespace dedicated to a client. Each client gets its own namespace. Client roles are managed under the Roles tab under each individual client. You interact with this UI the same way you do for realm-level roles.
If the client has to explicitly request another client’s role, the role has to be prexed with the client ID when performing a request using the scope parameter. For example, if the client ID is account and the role is admin, the scope parameter is:
`scope=account/admin`
As noted in the realm roles section, multiple roles are separated by spaces.
9.3. Composite Roles
Any realm or client level role can be turned into a composite role. A composite role is a role that has one or more additional roles associated with it. When a composite role is mapped to the user, the user also gains the roles associated with that composite. This inheritance is recursive so any composite of composites also gets inherited.
To turn a regular role into a composite role, go to the role detail page and ip the Composite Role switch on.
Composite Role
Once you ip this switch the role selection UI will be displayed lower on the page and you’ll be able to associate realm level and client level roles to the composite you are creating. In this example, the employee realm-level role was associated with the developer composite role. Any user with the developer role will now also inherit the employee role too.
When tokens and SAML assertions are created, any composite will also have its
associated roles added to the claims and assertions of the authentication response
sent back to the client.
9.4. User Role Mappings
User role mappings can be assigned individually to each user through the Role Mappings tab for that single user.
Role Mappings
In the above example, we are about to assign the composite role developer that was created in the Composite Roles chapter.
Eective Role Mappings
Once the developer role is assigned, you see that the employee role that is associated with the developer composite shows up in the Effective Roles. Effective Roles are all roles that are explicitly assigned to the user as well as any roles that are inherited from composites.
9.4.1. Default Roles
Default roles allow you to automatically assign user role mappings when any user is newly created or imported through Identity Brokering. To specify default roles go to the Roles left menu item, and click the Default Roles tab.
Default Roles
As you can see from the screenshot, there are already a number of default roles set up by default.
9.5. Client Scope
When an OIDC access token or SAML assertion is created, all the user role mappings of the user are, by default, added as claims within the token or assertion. Applications use this information to make access decisions on the resources controlled by that application. In XtremeCloud SSO, access tokens are digitally signed and can actually be re-used by the application to invoke on other remotely secured REST services. This means that if an application gets compromised or there is a rogue client registered with the realm, attackers can get access tokens that have a broad range of permissions and your whole network is compromised. This is where client scope becomes important.
Client scope is a way to limit the roles that get declared inside an access token. When a client requests that a user be authenticated, the access token they receive back will only contain the role mappings you’ve explicitly specied for the client’s scope. This allows you to limit the permissions each individual access token has rather than giving the client access to all of the user’s permissions. By default, each client gets all the role mappings of the user. You can view this in the Scope tab of each client.
Full Scope
You can see from the picture that the eective roles of the scope are every declared role in the realm. To change this default behavior, you must explicitly turn o the Full Scope Allowed switch and declare the specic roles you want in each individual client. Alternatively, you can also use client templates to dene the scope for a whole set of clients.
Partial Scope
10. Groups
Groups in XtremeCloud SSO allow you to manage a common set of attributes and role mappings for a set of users. Users can be members of zero or more groups. Users inherit the attributes and role mappings assigned to each group. To manage groups go to the Groups left menu item.
Groups
Groups are hierarchical. A group can have many subgroups, but a group can only have one parent. Subgroups inherit the attributes and role mappings from the parent. This applies to the user as well. So, if you have a parent group and a child group and a user that only belongs to the child group, the user inherits the attributes and role mappings of both the parent and child. In this example, we have a top level Sales group and a child North America subgroup. To add a group, click on the parent you want to add a new child to and click New button. Select the Groups icon in the tree to make a top-level group. Entering in a group name in the Create Group screen and hitting Save will bring you to the individual group management page.
Group
The Attributes and Role Mappings tab work exactly as the tabs with similar names under a user. Any attributes and role mappings you dene will be inherited by the groups and users that are members of this group.
To add a user to a group you need to go all the way back to the user detail page and click on the Groups tab there.
User Groups
Select a group from the Available Groups tree and hit the join button to add the user to a group. Vice versa to remove a group. Here we’ve added the user Jim to the North America sales group. If you go back to the detail page for that group and select the Membership tab, Jim is now displayed there.
Group Membership
10.1. Groups vs. Roles
In the IT world the concepts of Group and Role are often blurred and interchangeable. In XtremeCloud SSO, Groups are just a collection of users that you can apply roles and attributes to in one place. Roles dene 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 dierence is conceptual. Composite roles should be used to apply the permission model to your set of services and applications. Groups should focus on collections of users and their roles in your organization. Use groups to manage users. Use composite roles to manage applications and services.
10.2. Default Groups
Default groups allow you to automatically assign group membership whenever any new user is created or imported through Identity Brokering. To specify default groups go to the Groups left menu item, and click the Default Groups tab.
Default Groups
11. Admin Console Access Control and Permissions
Each realm created on the XtremeCloud SSO has a dedicated Admin Console from which that realm can be managed. The master realm is a special realm that allows admins to manage more than one realm on the system. You can also dene ne-grained access to users in dierent realms to manage the server. This chapter goes over all the scenarios for this.
11.1. Master Realm Access Control
The master realm in XtremeCloud SSO is a special realm and treated dierently than other realms. Users in the XtremeCloud SSO master realm can be granted permission to manage zero or more realms that are deployed on the XtremeCloud SSO server. When a realm is created, XtremeCloud SSO automatically creates various roles that grant ne-grain permissions to access that new realm. Access to The Admin Console and Admin REST endpoints can be controlled by mapping these roles to users in the master realm. It’s possible to create multiple super users, as well as users that can only manage specic 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 Specic Roles
Admin users within the master realm can be granted management privileges to one or more other
realms in the system. Each realm in XtremeCloud SSO is represented by a client in the master realm. The name
of the client is
The roles available are:
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 specic 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 specic 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 denes 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 specic part of the administration console.
11.3. Fine Grain Admin Permissions
Sometimes roles like manage-realm or manage-users are too coarse grain and you want to create restricted admin accounts that have more ne grain permissions. XtremeCloud SSO allows you to dene and assign restricted access policies for managing a realm. Things like:
Managing one specic client
Managing users that belong to a specic group
Managing membership of a group
Limited user management.
Fine grain impersonization control
Being able to assign a specic restricted set of roles to users.
Being able to assign a specic restricted set of roles to a composite role.
Being able to assign a specic restricted set of roles to a client’s scope.
New general policies for viewing and managing users, groups, roles, and clients.
There’s some important things to note about ne grain admin permissions:
Fine grain admin permissions were implemented on top of Authorization Services
(http://www.XtremeCloud SSO.org/docs/3.4/authorization_services/). It is highly recommended that you read up on
those features before diving into ne grain permissions.
Fine grain permissions are only available within dedicated admin consoles and admins dened
within those realms. You cannot dene cross-realm ne grain permissions.
Fine grain permissions are used to grant additional permissions. You cannot override the default
behavior of the built in admin roles.
11.3.1. Managing One Specic Client
Let’s look rst at allowing an admin to manage one client and one client only. In our example we have a realm called test and a client called sales-application. In realm test we will give a user in that realm permission to only manage that application.
You cannot do cross realm ne grain permissions. Admins in the master realm are
limited to the predened admin roles dened in previous chapters.
Permission Setup
The rst thing we must do is login to the Admin Console so we can set up permissions for that client. We navigate to the management section of the client we want to dene ne-grain permissions for.
Client Management
You should see a tab menu item called Permissions. Click on that tab.
Client Permissions Tab
By default, each client is not enabled to do ne grain permissions. So turn the Permissions Enabled switch to on to initialize permissions.
If you turn the Permissions Enabled switch to o, it will delete any and all
permissions you have dened for this client.
Client Permissions Tab
When you witch Permissions Enabled to on, it initializes various permission objects behind the scenes using Authorization Services(http://www.XtremeCloud SSO.org/docs/3.4/authorization_services/). For this example, we’re interested in the manage permission for the client. Clicking on that will redirect you to the permission that handles the manage permission for the client. All authorization objects are contained in the realm-management client’s Authorization tab.
Client Manage Permission
When rst initialized the manage permission does not have any policies associated with it. You will need to create one by going to the policy tab. To get there fast, click on the Authorization link shown in the above image. Then click on the policies tab.
There’s a pull down menu on this page called Create policy. There’s a multitude of policies you can dene. You can dene a policy that is associated with a role or a group or even dene rules in Javascript. For this simple example, we’re going to create a User Policy.
User Policy
This policy will match a hard-coded user in the user database. In this case it is the sales-admin user. We must then go back to the sales-application client’s manage permission page and assign the policy to the permission object.
Assign User Policy
The sales-admin user can now has permission to manage the sales-application client.
There’s one more thing we have to do. Go to the Role Mappings tab and assign the query-clients role to the sales-admin.
Assign query-clients
Why do you have to do this? This role tells the Admin Console what menu items to render when the sales-admin visits the Admin Console. The query-clients role tells the Admin Console that it should render client menus for the sales-admin user.
IMPORTANT If you do not set the query-clients role, restricted admins like sales-admin will not see any menu options when they log into the Admin Console
Testing It Out.
Next we log out of the master realm and 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
This admin is now able to manage this one client.
11.3.2. Restrict User Role Mapping
Another thing you might want to do is to restrict the set a roles an admin is allowed to assign to a user. Continuing our last example, let’s expand the permission set of the ‘sales-admin’ user so that he can also control which users are allowed to access this application. Through ne grain permissions we can enable it so that the sales-admin can only assign roles that grant specic access to the sales- application. We can also restrict it so that the admin can only map roles and not perform any other types of user administration.
The sales-application has dened three dierent client roles.
Sales Application Roles
We want the sales-admin user to be able to map these roles to any user in the system. The rst step to do this is to allow the role to be mapped by the admin. If we click on the viewLeads role, you’ll see that there is a Permissions tab for this role.
View Leads Role Permission Tab
If we click on that tab and turn the Permissions Enabled on, you’ll see that there are a number of actions we can apply policies to.
View Leads Permissions
The one we are interested in is map-role. Click on this permission and add the same User Policy that was created in the earlier example.
Map-roles Permission
What we’ve done is say that the sales-admin can map the viewLeads role. What we have not done is specify which users the admin is allowed to map this role too. To do that we must go to the Users section of the admin console for this realm. Clicking on the Users left menu item brings us to the users interface of the realm. You should see a Permissions tab. Click on that and enable it.
Users Permissions
The permission we are interested in is map-roles. This is a restrictive policy in that it only allows admins the ability to map roles to a user. If we click on the map-roles permission and again add the User Policy we created for this, our sales-admin will be able to map roles to any user.
The last thing we have to do is add the view-users role to the sales-admin. This will allow the admin to view users in the realm he wants to add the sales-application roles to.
Add view-users
Testing It Out.
Next we log out of the master realm and 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.
You will see that now the sales-admin can view users in the system. If you select one of the users you’ll see that each user detail page is read only, except for the Role Mappings tab. Going to these tab you’ll nd that there are no Available roles for the admin to map to the user except when we browse the sales-application roles.
Add viewLeads
We’ve only specied that the sales-admin can map the viewLeads role.
Per Client map-roles Shortcut
It would be tedious if we had to do this for every client role that the sales-application published. to make things easier, there’s a way to specify that an admin can map any role dened by a client. If we log back into the admin console to our master realm admin and go back to the sales-application permissions page, you’ll see the map-roles permission.
Client map-roles Permission
If you grant access to this particular parmission to an admin, that admin will be able map any role dened by the client.
11.3.3. Full List of Permissions
You can do a lot more with ne grain permissions beyond managing a specic client or the specic roles of a client. This chapter denes the whole list of permission types that can be described for a realm.
Role
When going to the Permissions tab for a specic role, you will see these permission types listed.
map-role
Policies that decide if an admin can map this role to a user. These policies only specify that the role
can be mapped to a user, not that the admin is allowed to perform user role mapping tasks. The
admin will also have to have manage or role mapping permissions. See Users Permissions for more
information.
map-role-composite
Policies that decide if an admin can map this role as a composite to another role. An admin can dene
roles for a client if he has manage permissions for that client but he will not be able to add
composites to those roles unless he has the map-role-composite privileges for the role he wants to
add as a composite.
map-role-client-scope
Policies that decide if an admin can apply this role to the scope of a client. Even if the admin can
manage the client, he will not have permission to create tokens for that client that contain this role
unless this privilege is granted.
Client
When going to the Permissions tab for a specic client, you will see these permission types listed.
view
Policies that decide if an admin can view the client’s conguration.
manage
Policies that decide if an admin can view and manage the client’s conguration. There is some issues
with this in that privileges could be leaked unintentionally. For example, the admin could dene a
protocol mapper that hardcoded a role even if the admin does not have privileges to map the role to
the client’s scope. This is currently the limitation of protocol mappers as they don’t have a way to
assign individual permissions to them like roles do.
configure
Reduced set of prileges to manage the client. Its like the manage scope except the admin is not
allowed to dene protocol mappers, change the client template, or the client’s scope.
map-roles
Policies that decide if an admin can map any role dened by the client to a user. This is a shortcut,
easy-of-use feature to avoid having to den policies for each and every role dened by the client.
map-roles-composite
Policies that decide if an admin can map any role dened by the client as a composite to another role.
This is a shortcut, easy-of-use feature to avoid having to dene policies for each and every role
dened by the client.
map-roles-client-scope
Policies that decide if an admin can map any role dened by the client to the scope of another client.
This is a shortcut, easy-of-use feature to avoid having to dene policies for each and every role
dened by the client.
ユーザー
When going to the Permissions tab for all users, you will see these permission types listed.
view
Policies that decide if an admin can view all users in the realm.
manage
Policies that decide if an admin can manage all users in the realm. This permission grants the admin
the privilege to perfor user role mappings, but it does not specify which roles the admin is allowed to
map. You’ll need to dene the privilege for each role you want the admin to be able to map.
map-roles
This is a subset of the privileges granted by the manage scope. In this case the admin is only allowed
to map roles. The admin is not allowed to perform any other user management operation. Also, like
manage, the roles that the admin is allowed to apply must be specied per role or per set of roles if
dealing with client roles.
manage-group-membership
Similar to map-roles except that it pertains to group membership: which groups a user can be
added or removed from. These policies just grant the admin permission to manage group
membership, not which groups the admin is allowed to manage membership for. You’ll have to
specify policies for each group’s manage-members permission.
impersonate
Policies that decide if the admin is allowed to impersonate other users. These policies are applied to
the admin’s attributes and role mappings.
user-impersonated
Policies that decide which users can be impersonated. These policies will be applied to the user being
impersonated. For example, you might want to dene a policy that will forbid anybody from
impersonating a user that has admin privileges.
Group
When going to the Permissions tab for a specic group, you will see these permission types listed.
view
Policies that decide if the admin can view information about the group.
manage
Policies that decide if the admin can manage the conguration of the group.
view-members
Policies that decide if the admin can view the user details of members of the group.
manage-members
Policies that decide if the admin can manage the users that belong to this group.
manage-membership
Policies that decide if an admin can change the membership of the group. Add or remove members
from the group.
11.4. Realm Keys
The authentication protocols that are used by XtremeCloud SSO require cryptographic signatures and sometimes encryption. XtremeCloud SSO uses asymmetric key pairs, a private and public key, to accomplish this.
XtremeCloud SSO 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 certicate 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. XtremeCloud SSO 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 rst 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 tradeo 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 oine 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 certicate.
Changing the priority for a provider will not cause the keys to be re-generated, but if you want to change the keysize you can edit the provider and new keys will be generated.
11.4.3. Adding an existing keypair and certicate
To add a keypair and certicate obtained elsewhere select Providers and choose rsa from the dropdown. You can change the priority to make sure the new keypair becomes the active keypair.
Click on Select file for Private RSA Key to upload your private key. The le should be encoded in PEM format. You don’t need to upload the public key as it is automatically extracted from the private key.
If you have a signed certicate for the keys click on Select file next to X509 Certificate. If you don’t have one you can skip this and a self-signed certicate will be generated.
11.4.4. Loading keys from a Java Keystore
To add a keypair and certicate stored in a Java Keystore le 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 conguration 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 conguration screen for the key provider for the keys. Click on Enabled to turn it OFF, then click on Save. The keys will no longer be enabled.
Alternatively, you can delete the provider from the Providers table.
11.4.7. Compromised keys
XtremeCloud SSO has the signing keys stored just locally and they are never shared with the client applications, users or other entities. However if you think that your realm signing key was compromised, you should rst 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
XtremeCloud SSO, hence the tokens signed by the compromised key won’t be valid anymore. Note that your REST and condential clients must have set Admin URL, so that XtremeCloud SSO is able to send them the request about pushed not-before policy.
12. アイデンティティー・ブローカリング
アイデンティティー・ブローカーは、複数のサービス・プロバイダーを異なるアイデンティティー・プロバ
イダーに接続する仲介サービスです。仲介サービスとして、アイデンティティー・ブローカーは、サービ
ス・プロバイダーによって公開される内部サービスへのアクセスでアイデンティティーを使用するために、
外部アイデンティティー・プロバイダーとの信頼関係を作成する責任があります。
ユーザーの観点から、アイデンティティー・ブローカーは、異なるセキュリティ・ドメインまたはレルム間
のアイデンティティーを管理するための、ユーザー中心かつ一元的な方法を提供します。既存のアカウント
は、異なるアイデンティティー・プロバイダーの 1 つ以上のアイデンティティーとリンクすることも、それら
から取得したアイデンティティー情報に基づいて作成することもできます。
An identity provider is usually based on a specic protocol that is used to authenticate and communicate authentication and authorization information to their users. It can be a social provider such as Facebook, Google or Twitter. It can be a business partner whose users need to access your services. Or it can be a cloud-based identity service that you want to integrate with.
通常、アイデンティティー・プロバイダーは次のプロトコルに基づいて実装されています。
SAML v2.0
OpenID Connect v1.0
OAuth v2.0
次のセクションでは、XtremeCloud SSOをアイデンティティー・ブローカーとして設定および使用する方法を説明し ます。以下のいくつかの重要な側面について説明します。
Social Authentication
OpenID Connect v1.0 Brokering
SAML v2.0 Brokering
Identity Federation
12.1. ブローカリングの概要
XtremeCloud SSOをアイデンティティー・ブローカーとして使用する場合、ユーザーは特定のレルムで認証するため にクレデンシャルを提供する必要はありません。代わりに、認証可能なアイデンティティー・プロバイダー のリストが提示されます。
また、デフォルトのブローカーを設定することもできます。この場合、ユーザーには選択肢が与えられず、
親のブローカーに直接リダイレクトされます。
次の図は、XtremeCloud SSOを使用して外部アイデンティティー・プロバイダーを仲介するときに、必要な手順を示 しています。
アイデンティティー・ブローカーのフロー
1. ユーザーは認証しておらず、クライアント・アプリケーションの保護されたリソースを要求します。
2. クライアント・アプリケーションは、ユーザーを認証するためにXtremeCloud SSOにリダイレクトさせます。
3. この時点で、ユーザーにはログイン・ページが表示されます。ログイン・ページには、レルムがサポー
トするアイデンティティー・プロバイダーのリストがあります。
4. ユーザーは、各ボタンまたはリンクをクリックしてアイデンティティー・プロバイダーの 1 つを選択しま
す。
5. XtremeCloud SSOは、ターゲットのアイデンティティー・プロバイダーに認証を要求する認証リクエストを発行
し、ユーザーはアイデンティティー・プロバイダーのログイン・ページにリダイレクトされます。アイ
デンティティー・プロバイダーの接続プロパティとその他の設定オプションは、管理者が管理コンソー
ルで前もって設定したものになります。
6. ユーザーは、アイデンティティー・プロバイダーで認証するためにクレデンシャルまたは同意を提供し
ます。
7. アイデンティティー・プロバイダーによる認証が成功すると、ユーザは認証レスポンスとともに
XtremeCloud SSOにリダイレクトされます。通常、このレスポンスには、XtremeCloud SSOによって使用されるセキュリ
ティ・トークンが含まれています。セキュリティ・トークンは、アイデンティティー・プロバイダーに
よって実行された認証を信頼し、そのユーザーに関する情報を取得するために使用されます。
8. XtremeCloud SSO checks if the response from the identity provider is valid. If enabled, import new user or
create it, or skip if the user already exists. For new users, XtremeCloud SSO may contact the identity provider
if information about the user does not already exist in the token. This is what we call identity
federation. If the user already exists, XtremeCloud SSO may ask you to link the identity returned from the
identity provider to the existing account. This process is called account linking. What can be done
accurately is congurable and can be specied in First Login Flow setting. At the end of this step,
XtremeCloud SSO authenticates the user and issues its own token to access the service provider's requested
resource.
9. Once the user is authenticated locally, XtremeCloud SSO will redirect the user to the service provider by
sending the previously issued token during local authentication.
10. The service provider receives the token from XtremeCloud SSO and grants access to the protected resource.
There are several variations in this ow, so I will explain later. For example, instead of presenting a list of identity providers, the client application can request a specic provider. Or you can tell XtremeCloud SSO to force the user to provide additional information before the user integrates their identity.
Dierent protocols may require dierent authentication ows. Currently, all Identity
Providers supported by XtremeCloud SSO will use the ow as described above. However,
regardless of the protocol used, the user experience should be about the same.
As you may have noticed, at the end of the authentication process XtremeCloud SSO always publishes its own token to the client application. This means that the client application is completely separated from the external identity provider. Client applications do not need to know which protocol (eg SAML, OpenID Connect, OAuth etc.) was used or how the user’s identity was veried, only need to know about XtremeCloud SSO.
12.2. Default Identity Provider
Instead of displaying the login form, it is possible to redirect automatically to the identity provider. AuthenticationGo to go to enable this and Browserselect the ow. Next, Identity Provider Redirectorclick the setting of the authenticator. Default Identity ProviderTo the alias of the
identity provider that automatically redirects the user.
If you do not nd the default identity provider configured, the login form is displayed instead.
This authenticator is kc_idp_hintalso responsible for handling query parameters. For more information, please refer to the Client Proposed Identity Provider section.
12.3. Common settings
All identity broker settings are based on an identity provider. An identity provider is created for each realm, and by default is enabled for each single application. In other words, users of realms can use one of the registered identity providers when signing in to the application.
To create an identity provider Identity Providers, click on the left side.
Identity Providers
In the drop down list box, select the identity provider you want to add. This displays the Identity Provider Type Conguration page.
Add Identity Provider
The above is an example of setting up Google’s social login provider. Once you set up IDP, it appears as an option on XtremeCloud SSO’s login page.
IDP login page
social
Social providers can enable social authentication in the realm. XtremeCloud SSO allows users to log in to
applications easily using existing accounts in social networks. Currently, Facebook, Google, Twitter,
GitHub, LinkedIn, Microsoft, StackOverow are supported, and further additions are planned in the
future.
Protocol base
プロトコル・ベースのプロバイダーは、特定のプロトコルに依存してユーザーを認証および認可するもの
です。特定のプロトコルに準拠しているすべてのアイデンティティー・プロバイダーに接続できます。
XtremeCloud SSOはSAML v2.0とOpenID Connect v1.0プロトコルをサポートしています。これにより、これらの
オープンスタンダードに基づいた任意のアイデンティティー・プロバイダーを簡単に設定および仲介でき
るようになります。
各タイプのアイデンティティー・プロバイダーには独自の設定オプションがありますが、すべて共通の設定 を共有しています。作成しているアイデンティティー・プロバイダに関係なく、次の設定オプションが使用 できます。
Table 1. 共通の設定
設定 説明
Alias エイリアスは、アイデンティティー・プロバイダ の一意な識別子です。アイデンティティー・プロ バイダーを内部的に参照するために使用されま す。 OpenID Connectなどの一部のプロトコルで は、アイデンティティー・プロバイダーと通信す るために、リダイレクトURIまたはコールバック URLが必要です。 この場合、エイリアスはリダイ レクトURIを構築するために使用されます。 すべて のアイデンティティー・プロバイダーにエイリア スが必要です。例としては、facebook、google、 idp.acme.comなどです。
Enabled プロバイダーのオン/オフ
Hide On Login Page このスイッチがオンの場合、このプロバイダーは ログイン・ページにログイン・オプションとして 表示されません。クライアントは、ログインを要 求するために使用するURLの ‘kc_idp_hint’ パラメ ーターを使用して、このプロバイダーの使用を引 き続き依頼できます。
Link Only このスイッチをオンにすると、このプロバイダー はユーザーのログインでは使用することができ ず、ログイン・ページにはオプションとして表示 されません。しかし、既存のアカウントはこのプ ロバイダーとリンクできます。
Store Tokens アイデンティティー・プロバイダーから受け取っ たトークンを保存するかどうか。
Stored Tokens Readable ユーザーは保存されたアイデンティティー・プロ バイダー・トークンを取得できるかどうか。 broker クライアント・レベルのロール read token にも適用されます。
Trust email アイデンティティー・プロバイダーがメールアド レスを提供する場合、このメールアドレスは信頼 されます。レルムに電子メールの検証が必要な場 合、このIDPからログインしたユーザーは電子メー ルの検証プロセスを経る必要はありません。
GUI order 利用可能なIDPがXtremeCloud SSOログイン・ページにどの
ように表示されるかを並べ替えるオーダー番号。
First Login Flow このIDPを通じて、初めてXtremeCloud SSOにログインする
ユーザーのためにトリガーされる認証フローで
す。
Post Login Flow ユーザーが外部アイデンティティー・プロバイダ
ーへのログインを完了した後にトリガーされる認
証フロー。
12.4. ソーシャル・アイデンティティー・プロバイダー
インターネット上のアプリケーションでは、ユーザーはアクセスするためにサイトに登録する必要がありま
す。さらに別のユーザー名とパスワードの組み合わせを覚えておく必要があります。ソーシャル・アイデン
ティティー・プロバイダーを使用すると、ユーザーはすでにアカウントを持っている可能性のある、ある程
度信頼性があり評判のよい事業者に認証を委譲することができます。XtremeCloud SSOは、Google、Facebook、 Twitter、Github、LinkedIn、Microsoft、StackOverowなど、最も一般的なソーシャル・ネットワークのビ ルトイン・サポートを提供しています。
12.4.1. Google
There are a number of steps you have to complete to be able to login to Google. First, go to the Identity Providers left menu item and select Google from the Add provider drop down list. This will bring you to the Add identity provider page.
アイデンティティー・プロバイダーの追加
You can’t click save yet, as you’ll need to obtain a Client ID and Client Secret from 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 XtremeCloud SSO as a client there, so copy this URI to your clipboard.
To enable login with Google you rst have to create a project and a client in the Google Developer Console(https://console.cloud.google.com/project). Then you need to copy the client id and secret into the XtremeCloud SSO 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 conguration steps might be slightly
dierent.
Let’s see rst how to create a project with Google.
Log in to the Google Developer Console(https://console.cloud.google.com/project).
Google Developer Console
Click the Create Project button. Use any value for Project name and Project ID you want, then click the Create button. 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 proles of Google users, you need to turn on the Google+ APIs. Select the Enable and manage APIs and click the Google+ API link.
APIs
Click the Enable button on this page. You will get a message that you must create the credentials of your project. So click the Go to Credentials button.
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
Manager and 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
Select Web server and User data and 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 URI from the XtremeCloud SSO Add Identity Provider page into the Authorized redirect URIs eld. After you do this, click the Create client ID button.
When users log into Google from XtremeCloud SSO they will see a consent screen from Google which will ask the user if XtremeCloud SSO is allowed to view information about their user prole. The next Google cong screen asks you for information about this screen.
Once you click Done you will be brought to the Credentials page. 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 XtremeCloud SSO Add identity provider page. Go back to XtremeCloud SSO and specify those items.
One cong option to note on the Add identity provider page for Google is the Default Scopes eld. This eld allows you to manually specify the scopes that users must authorize when authenticating with this provider. For a complete list of scopes, please take a look at https://developers.google.com/oauthplayground/. By default, XtremeCloud SSO uses the following scopes: openid profile email.
12.4.2. Facebook
To log in to Facebook, you have to complete several steps. First, go to Identity Providersthe left menu item and select Add providerfrom the drop down list Facebook. This Add identity providerwill bring up the page.
Add Identity Provider
From the Facebook Client IDcapital Client Secretbecause there is a need to get a, you will not be able to click the still save button. One of the required input data on this page Redirect URIis. Copy this URI to the clipboard as it is necessary to provide XtremeCloud SSO on Facebook as a client when registering as a client.
To enable login on Facebook(https://developers.facebook.com/) , you rst need to create projects and clients in the Facebook Developer Console(https://developers.facebook.com/).
Since Facebook often changes the design of the Facebook Developer Console, these
instructions are not always up-to-date and the setup procedure may dier slightly.
When you log in to the console, My Appsa pull-down menu will appear on the top right corner of the screen. Add a New AppSelect the menu item.
Add a new application
WebsiteSelect an icon. Skip and Create App IDClick the button.
Create a new App ID
The email address and category of the application are mandatory elds. When you are done, you will be taken to the application’s dashboard. SettingsPlease click the menu item on the left of.
Create a new App ID
+ Add PlatformClick the button at the end of this page Websiteand select the icon. Copy the XtremeCloud SSO
Add identity providerpage and paste it on Redirect URIFacebook's Websiteconguration block
Site URL.
Specify website
この後、Facebookアプリを公開する必要があります。左のメニューの App Review をクリックし、ボタン を”Yes”に切り替えます。
このページからApp IDとApp Secretを取得して、XtremeCloud SSOの Add identity provider ページに入力する 必要があります。これを取得するには、左のメニュー項目 Dashboard をクリックし、 App Secret の下 の Show をクリックします。XtremeCloud SSOに戻り、これらの項目を指定し、最後にFacebookアイデンティティ ー・プロバイダーを保存します。
Facebook用の Add identity provider ページで注意が必要な 1 つの設定オプションは、 Default Scopes フィールドです。 このフィールドでは、このプロバイダーで認証するときに、ユーザーが承認する 必要があるスコープを手動で指定できます。スコープの完全なリストについては、 https://developers.facebook.com/docs/graph-api をご覧ください。デフォルトでは、XtremeCloud SSOは次のスコ ープを使用します: email 。
12.4.3. Twitter
There are a number of steps you have to complete to be able to login to Twitter. First, go to the Identity Providers left menu item and select Twitter from the Add provider drop down list. This will bring you to the Add identity provider page.
アイデンティティー・プロバイダーの追加
You can’t click save yet, as you’ll need to obtain a Client ID and Client Secret from 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 XtremeCloud SSO as a client there, so copy this URI to your clipboard.
To enable login with Twtter you rst have to create an application in the Twitter Application Management(https://apps.twitter.com).
Register Application
Click on the Create New App button. This will bring you to the Create an Application page.
Register Application
Enter in a Name and Description. The Website can be anything, but cannot have a localhost address. For the Callback URL you must copy the Redirect URI from the XtremeCloud SSO Add Identity Provider page.
You cannot use localhost in the Callback URL. Instead replace it with 127.0.0.1 if
you are trying to testdrive Twitter login on your laptop.
After clicking save you will be brought to the Details page.
App Details
Next go to the Keys and Access Tokens tab.
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 ID and Client Secret elds on the XtremeCloud SSO Add identity provider page.
12.4.4. Github
There are a number of steps you have to complete to be able to login to Github. First, go to the Identity Providers left menu item and select Github from the Add provider drop down list. This will bring you to the Add identity provider page.
Add Identity Provider
You can’t click save yet, as you’ll need to obtain a Client ID and Client Secret from 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 XtremeCloud SSO as a client there, so copy this URI to your clipboard.
To enable login with Github you rst have to register an application project in GitHub Developer applications(https://github.com/settings/developers).
Github often changes the look and feel of application registration, so these directions
might not always be up to date and the conguration steps might be slightly dierent.
Add a new application
Click the Register a new application button.
Register App
You’ll have to copy the Redirect URI from the XtremeCloud SSO Add Identity Provider page and enter it into the Authorization callback URL eld on the Github Register a new OAuth application page. 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 XtremeCloud SSO Add identity provider page. Go back to XtremeCloud SSO and specify those items.
12.4.5. LinkedIn
There are a number of steps you have to complete to be able to login to LinkedIn. First, go to the Identity Providers left menu item and select LinkedIn from the Add provider drop down list. This will bring you to the Add identity provider page.
アイデンティティー・プロバイダーの追加
You can’t click save yet, as you’ll need to obtain a Client ID and Client Secret from 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 XtremeCloud SSO as a client there, so copy this URI to your clipboard.
To enable login with LinkedIn you rst have to create an application in LinkedIn Developer Network (https://www.linkedin.com/developer/apps).
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 Application button. This will bring you to the Create a New Application Page.
Create App
Fill in the form with the approriate values, then click the Submit button. This will bring you to the new application’s settings page.
App Settings
Select r_basicprofile and r_emailaddress in the Default Application Permissions section. You’ll have to copy the Redirect URI from the XtremeCloud SSO Add Identity Provider page and enter it into the OAuth 2.0 Authorized Redirect URLs eld on the LinkedIn app settings page. Don’t forget to click the Update button 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 XtremeCloud SSO Add identity provider page. Go back to XtremeCloud SSO and specify those items.
12.4.6. Microsoft
There are a number of steps you have to complete to be able to login to Microsoft. First, go to the Identity Providers left menu item and select Microsoft from the Add provider drop down list. This will bring you to the Add identity provider page.
アイデンティティー・プロバイダーの追加
You can’t click save yet, as you’ll need to obtain a Client ID and Client Secret from 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 XtremeCloud SSO as a client there, so copy this URI to your clipboard.
To enable login with Microsoft account you rst have to register an OAuth application at Microsoft. Go to the Microsoft Application Registration(https://account.live.com/developers/applications/create) url.
Microsoft often changes the look and feel of application registration, so these directions
might not always be up to date and the conguration steps might be slightly dierent.
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 URI from the XtremeCloud SSO Add Identity Provider page and add it to the Redirect URIs eld on the Microsoft application page. Be sure to click the Add Url button and Save your changes.
Finally, you will need to obtain the Application ID and secret from this page so you can enter them back on the XtremeCloud SSO Add identity provider page. Go back to XtremeCloud SSO and specify those items.
12.4.7. PayPal
There are a number of steps you have to complete to be able to login to PayPal. First, go to the Identity Providers left menu item and select PayPal from the Add provider drop down list. This will bring you to the Add identity provider page.
アイデンティティー・プロバイダーの追加
You can’t click save yet, as you’ll need to obtain a Client ID and Client Secret from 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 XtremeCloud SSO as a client there, so copy this URI to your clipboard.
To enable login with PayPal you rst have to register an application project in PayPal Developer applications(https://developer.paypal.com/developer/applications).
新しいアプリケーションの追加
Click the Create App button.
Register App
You will now be brought to the app settings page.
12.4.8. Do the following changes:
Choose to congure either Sandbox or Live (choose Live if you haven’t enabled the Target Sandbox
switch on the Add identity provider page)
Copy Client ID and Secret so you can paste them into the XtremeCloud SSO Add identity provider page.
Scroll down to App Settings
Copy the Redirect URI from the XtremeCloud SSO Add Identity Provider page and enter it into the
Return URL eld.
Check the Log In with PayPal checkbox.
Check the Full name checkbox under the personal information section.
Check the Email address checkbox under the address information section.
Add both a privacy and a user agreement URL pointing to the respective pages on your domain.
12.4.9. StackOverow
There are a number of steps you have to complete to be able to login to StackOverow. First, go to the Identity Providers left menu item and select StackOverflow from the Add provider drop down list. This will bring you to the Add identity provider page.
Add Identity Provider
To enable login with StackOverow you rst have to register an OAuth application on StackApps (https://stackapps.com/). Go to registering your application on Stack Apps (https://stackapps.com/apps/oauth/register) url and login.
StackOverow often changes the look and feel of application registration, so these
directions might not always be up to date and the conguration steps might be slightly
dierent.
Register Application
Enter in the application name and the OAuth Domain Name of your application and click Register your Application. Type in anything you want for the other items.
Settings
Finally, you will need to obtain the client ID, secret, and key from this page so you can enter them back on the XtremeCloud SSO Add identity provider page. Go back to XtremeCloud SSO and specify those items.
12.4.10. Openshift
Openshift Online is currently in the developer preview mode. This documentation has
been based on on-premise installations and local minishift development
environment.
There are a just a few steps you have to complete to be able to login to OpenShift. First, go to the Identity Providers left menu item and select Openshift from the Add provider drop down list. This will bring you to the Add identity provider page.
Add Identity Provider
Registering OAuth client
You can register your client using oc command line tool.
$ oc create -f <(echo '
kind: OAuthClient
apiVersion: v1
metadata:
name: kc-client
secret: "..."
redirectURIs:
- “http://www.example.com/” grantMethod: prompt ‘)
BASH
1
2
3
4
1
The name of your OAuth client. Passed as client_id request parameter when making
requests to <openshift_master>/oauth/authorize and
<openshift_master>/oauth/token.
(^2) secret is used as the client_secret request parameter. 3 The redirect_uri parameter specied in requests to