Elevate SSO Options

Elevate SSO Options

1) Cookie-based token, with login form on Elevate:

1. When a user arrives on Elevate, and is not currently logged in on Elevate, it looks for a cookie containing an SSO token from the main site.
2. If it does not find one, it displays a login form on the menu, and treats the user as a "guest". 
3. If it does find the SSO token cookie, Elevate uses a webservice at the client's website or AMS to validate that token, and get user information, log them in and treat them as a logged in user. The client's webservice should provide token validation, as well as user information, including member-type information. This can be all in one webservice call or many. We will program our site to make whatever calls are needed. 
4. If a guest user fills in the login form and submits, Elevate uses a different webservice at the client's site or AMS to validate the username and password, then logs them in on Elevate. 

This requires the client to supply web services for: 

• Token validation 
• Username/Password validation
• User information 
• The client must also place SSO token cookies when user logs in on their site
• The client must point a sub-domain that matches their main site to Elevate, so we can host under a domain where we can read shared cookies
  
  

2) Cookie based, with login on client's site

1. When a user arrives on Elevate, and is not currently logged in on Elevate, it looks for a cookie containing an SSO token from the main site. 
2. If it does not find one, it displays a login button on the menu, and treats the user as a "guest". 
3. If it does find the SSO token cookie, Elevate uses a webservice at the client's website or AMS to validate the token, get user information, log them in, and treat them as a logged in user. The client's webservice should provide token validation, as well as user information, including member-type information. This can be all in one webservice call or many. We will program our site to make whatever calls are needed. 
4. If a guest user clicks the login button, it takes them to the client's website login page. If a user logs in on the client site, the client site must redirect them back to Elevate with an SSO token cookie, then Elevate will validate them with the same webservice used in 2c above. 

This requires the client to supply web services for: 

• Token validation
• User information
• The client must also place SSO token cookies when user logs in on their site
• The client's login page must accept some sort of "return URL" parameter so we can tell them where to send the user back to after login
• The client must point a sub-domain that matches their main site to Elevate, so we can host under a domain where we can read shared cookies
  
  

3) Query-string token, with login form on Elevate

Very much like #1 above, except that the client's system does not or cannot place any cookie with an SSO token in it for us to read. This limits the SSO functionality somewhat.

1. When a user arrives on Elevate, and is not currently logged in on Elevate, it looks for a query string parameter containing an SSO token from the main site. 
2. Users arriving on Elevate without any SSO token in the query string will be treated as guests, and will see a login form on the menu. 
3. Links that the client provides from the client's website pointed to Elevate which include the SSO token in the query string will automatically log users in, very much like 1c above. 
4. Guest users completing the login form here will be validated and logged in similar to 1d above. 

This requires the client to supply web services for: 

• Token validation
• Username/Password validation
• User information
• The client must be able to make dynamic links on their website which include the SSO token in the query string
  
  

4) Query-string token, with login on client's site

1. When a user arrives on Elevate, and is not currently logged in on Elevate, it looks for a query string parameter containing an SSO token from the main site.
2. Users arriving at Elevate without any SSO token in the query string will be treated as guests, and will see a login form on the menu. 
3. Links that the client provides from the client's website pointed to Elevate which include the SSO token in the query string will automatically log users in here, very much like 1c above. 
4. If a guest user clicks the login button, it takes them to the client's website login page. If a user logs in on the client site, the client site must redirect them back to Elevate with an SSO token parameter in the query string, then Elevate will validate them with the same webservice used in 4c above. 

This requires the client to supply web services for: 

• Token validation
• User information
• The client must be able to make dynamic links on their website which include the SSO token in the query string
• The client's login page must accept some sort of "return URL" parameter so we can tell them where to send the user back to after login, and when that redirect occurs, they must include the SSO token in the return URL.
  
  

Process:

1. Pick one of the SSO options above 
2. Provide your custom domains with the CNAME pointed to elevate.commpartners.com
3. Provide Elevate with information about your webservices, login pages, etc. that are needed to accomplish the SSO, as well as a few test user credentials, preferably each with different member-type information.