How it works

QuickBuild supports single sign-on by trusting specified http header from specified ip address like below:

Normally you should configure a front end such as Apache httpd to actually authenticate users and then forward the request to QuickBuild via mechanisms such as reverse proxy. The front-end should be configured appropriately to contain user logon name in specified http header, and QuickBuild will use that to identify authenticated user. If authenticators are defined, QuickBuild will look up additional user information in authenticators, including user groups, full name, email etc; otherwise, the user group will initinally be set to default group defined above, and other information will be left empty.

Examples

Check here for examples of Single Sign-On setup.

Impacts on user agent, RESTful API access, and tray monitor

User agent, RESTful API access and tray monitor have to authenticate to QuickBuild with user name and password. However for performance considerations, QuickBuild will not call external authenticators for credential verification, instead, it verifies password against the password hash recorded in QuickBuild's own database. In a single sign-on setup, QuickBuild will never receive the password when the user is created, so it will generate a random password hash in the database. This requires the user to logon to QuickBuild to change the password, and then use changed password for user agent, RESTful API access, or tray monitor.

In summary, the password used to access QB web UI will be the password maintained in external authenticator systems, and you will not need to input that in a single sign-on setup, while the password used to access QB services is maintained separately inside QuickBuild, and should be changed initially via QuickBuild user profile page.