Single Sign-On with Signed URL Redirects (Convio CRM)

gpeck

This document describes a single sign-on protocol with signed URL redirects. A Convio-powered site handles login authentication, and a partner web site hosts the login form. No assumption is made about the two sites sharing cookies.

Adrian Cotter

Is this usable now? or is this just a proposal? If it is a proposal when is it likely to be implemented?

Eric Miller

Yep, this SSO methodology is currently available with no extra platform configs needed**.

**In order to use the server-side API methods, additional platform configs would be needed, assuming you haven't already had that set up.

Adrian Cotter

Hey emiller,

Thanks. Is this sso_secret referred to in the documentation (below) the same things as the api_key that we set under setup - site options in Convio? Or something else?

Eric Miller

It doesn't have to be the same as the api_key, but there's nothing in place that would prevent you from using the same string for both. It's certainly easier to use the same value, though some might argue that doing so weakens the security.

gpeck

Just to clarify a little more... These are two distinctly differently items, but they can be set to the same value. The two items are completely unaware of one another. And I echo Eric's ease vs security comment.

David Hart

They should absolutely be different. The API key is very public and not at all secret. This method puts a lot of faith in the fact that if a URL has been signed with the key, it had to come from Convio.

Kofi Hamilton

Quick question:

Is the login form on my site pointing to Convio or a script on my website.

i.e: is it < form action='http://mysite.com/login.py' > or < form action='http://secure2.convio.net/login' >

If it's pointing to a script on my website, then, should I using the getSingleSignOn/singleSignOn API calls to talk to the convio server??

gpeck

Hi Kofi,

You should check with your account manager for the specifics of your site, SSO is achieved in a variety of ways. Your question involves two unrelated techniques - "SSO with Signed URL Redirects" and the "SSO API".

This particular document describes "SSO with Signed URL Redirects" and gives login control to your Convio-powered site. For this to work, the login form would point to your Convio site with an action of 'http://www.foo.org/site/UserLogin'. Please note that you must use the correct URL to reach your Convio site. If you have www.foo.org hosted elsewhere and donations.foo.org is on Convio, then your login action would be http://donations.foo.org/site/UserLogin.

The SingleSignOn API on the other hand gives login control to your non-Convio site. In that example, the third party server authenticates the user and retrieves a short-life "token" prior to sending the user to Convio hosted pages. Convio references that token when determining login status. Details for the SSO API can be found at http://open.convio.com/api/sso-api/

Kofi Hamilton

Thanks for your answers gpeck,

1) The information you just provided should be put on http://open.convio.com/api/sso-api/ . It would have saved me 2 weeks of trying to figure this thing out.

2) I am the API account manager and I have already setup my account for getSingleSignOn API calls.

How do I set it up for "Single Sign-On with Signed URL Redirects". Please point me to documentation that shows me how.

3) Please unconfuse me on the issues below:

The documentation uses the url http://www.foo.org/site/UserLogin.

Don't you mean http://foo.convio.net/site/UserLogin

It also uses the url http://www.foo.org/site/PixelServer.

Don't you mean http://foo.convio.net/site/PixelServer

It also uses the url http://www.foo.org/site/UserLogin?logout=logout&NEXTURL=partner_logout_url

Don't you mean http://foo.convio.net/site/UserLogin?logout=logout&NEXTURL=partner_logout_url

gpeck

Hi Kofi,

1) I'll forward your comments to the API team for consideration. Taken together the three pages on the SSO API do say pretty much the same thing, but alternate ways to summarize it are always helpful. Thank you for this feedback.

2) The "SSO with Signed URL Redirects" document linked on this page outlines the steps to set this up. If you need help with any of the Convio tags or conditionals, please contact your account manager for additional guidance - be aware that we can only assist with the Convio hosted portion.

3) In the examples www.foo.org is used to indicate whatever domain or subdomain is appropriate for your Convio hosted site. Some clients use a distinct www.foo.org domain while others use a subdomain such as donate.foo.org. Ideally, clients do not use foo.convio.net - however there are some that do for their particular situation (most common in the case of migrated clients). If you use shortname.convio.net as your only way to get to Convio pages, that is what you would use in this case.

Sincerely,

Glen

robert@zakongroup.com

"If the login credentials are invalid, the user is redirected to the Convio-hosted UserLogin page. That page offers the user several options if he has not registered yet or has forgotten his password. Failed logins cannot be redirected to a page on the partner site -- an aspect of the user experience that individual clients may want tweaked."

So, how do client "tweak" the user experience?

gpeck

Hi Robert,

Your assessment is correct. Unfortunately there is not a way to readily "tweak" user experience here. This is a "Convio as Master" configuration and by definition it is the Convio system that needs to handle bad logins. The intent of this solution is to offer a fairly reliable SSO option for clients that does not require extensive programming or knowledge of server protocols to implement. For more robust management of the total user experience in a SSO scenario, you would need to go with more a complex option combining an external login system, programming languages and our SSO API to provide an alternate login experience driven by the third party server.

Sincerely,

Glen

gpeck

On second read, a point of clarity may be in order here... The inflection of the statement in question is not carrying through in print.

The intention of the statement is to say essentially, "Some client's may want to tweak the user experience by sending failed logins to the partner site. This is not possible."

Thank you for raising this question and drawing attention to the lack of clarity here. We will include more direct language in V2!

robert@zakongroup.com

Glen - I have been informed that beyond this document and the SSO API, Convio has a 3rd method for handling Convio-authenticated SSO documented on the internal wiki. Apparently it has something to do with checking a cookie set by the Convio system for the client's domain. Can you provide further information/documentation on this method? We need a working SSO solution that is Convio-authenticated as it is Convio that will be creating/storing all account & member information.

gpeck

Hi Robert,

The method you are referring to is the "Shared Cookies - Convio as Master" solution. Shared cookies can be a less stable solution in some configurations and we are stepping away from this as a broadly applicable option. With shared cookies there are domain dependencies and setup requirements that will require Convio interaction to establish. Additionally, deployment of the shared cookies method disables the .convio.net URL syntax which can result in broken links in some cases. For these reasons, any client with SSO needs not met by the "Single Sign-On with Signed URL Redirects" method described in this document should contact their Account Manager to discuss other options - or visit http://open.convio.com/api/sso-api/ in the case of our Convio as Slave SSO API.

For full disclosure, there are four common SSO solutions in use on Convio sites. Each solution has its own requirements and limitations so it is important that you consult with you AM to discuss the particulars of your situation. The solutions fall into two categories "Convio as Master" and "Convio as Slave" - the master/slave indicates which system is functioning as the master authenticator.

Convio as Master

1. "Single Sign-On with Signed URL Redirects" (a.k.a. URL hash authentication)

2. "Shared Cookies"

Convio as Slave

1. SSO API - see http://open.convio.com/api/sso-api/

2. "Cookie Authentication" (essentially same approach as c.a.m. 2, but with authentication outside Convio)

Sincerely,

Glen

gpeck

Hi Robert,

The method you are referring to is the "Shared Cookies - Convio as Master" solution. Shared cookies can be a less stable solution in some configurations and we are stepping away from this as a broadly applicable option. With shared cookies there are domain dependencies and setup requirements that will require Convio interaction to establish. Additionally, deployment of the shared cookies method disables the .convio.net URL syntax which can result in broken links in some cases. For these reasons, any client with SSO needs not met by the "Single Sign-On with Signed URL Redirects" method described in this document should contact their Account Manager to discuss other options - or visit http://open.convio.com/api/sso-api/ in the case of our Convio as Slave SSO API.

For full disclosure, there are four common SSO solutions in use on Convio sites. Each solution has its own requirements and limitations so it is important that you consult with you AM to discuss the particulars of your situation. The solutions fall into two categories "Convio as Master" and "Convio as Slave" - indicating which system is functioning as the master authenticator.

Convio as Master

1. "Single Sign-On with Signed URL Redirects" (a.k.a. URL hash authentication)

2. "Shared Cookies"

Convio as Slave

1. SSO API - see http://open.convio.com/api/sso-api/

2. "Cookie Authentication" (essentially same approach as c.a.m. 2, but with authentication outside Convio)

Sincerely,

Glen

Corey Pudhorodsky

Just a housekeeping note that there is a new SSO process that uses the Convio SSO APIs with Convio as master.  This document is located:

http://community.customer.convio.com/docs/DOC-2183

and streamlines some of the steps that were necessary in the previous method.