Single sign-on Support

Version 2 by Robin Shen
on Dec 04, 2014 12:18.

<< Changes from 1 to 2
compared with
Current by Robin Shen
on Dec 04, 2014 12:20.

 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 5 changes. View first change.

 h1. How it works
  
 QuickBuild supports single sign-on by trusting specified http header from specified ip address like below:
 !trust-http-header.png!
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.
  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.
  
 h1. Examples
Check here for examples of [single sign-on] setup.
  
Check here for examples of [Single Sign-On|single sign-on] setup.
  
 h1. 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.
   
 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.