Allow an idea portal to be linked to another system so that users of the other system were automatically authenticated to the ideas portal without the need to separately register or log in.
You can read about setting up JWT single sign-on for your ideas portal here: Setting up ideas portal SSO
Similar to other posts - we need single signon so users of our community hosted by Ning (ning) OR users of our product do not have to set up a separate account with Aha in order to submit, view, and rank ideas in the community. This idea site can't be publicly available as the data is extremely valuable and proprietary and we'd not want our competitors to benefit from our customer community.
We currently use Zendesk for Support and they have remote authentication to our platform for SSO, which we then provide to all of our users. It would be awesome if our users could use the same credentials to submit ideas to a private portal.
I had a look at the Crowd documentation. It doesn't look to me like they support any of the common SSO protocols like SAML or JWT. We are unlikely to add support for Crowd if they don't support SAML.
We're using Atlassian Crowd to manage our SSO with the various systems that we make available to our customers (Customer Support Portal, Wiki, Documentation, etc.) and would be very interested in having Aha! integrate directly with Crowd.
Yes, it would pass the email address and name of the user so these are pre-populated, just as if the user had logged in themselves.
Just to be clear, would this weaker SSO pass the initial username -- the one our client uses to log into our app -- to the ideas portal, so we know who the idea came from?
For us, a "weak" SSO would be fine - effectively a shared secret approach. We don't need a whole SSO/openauth type approach, I think that is overkill.
Many saas applications have a guid api key you can generate and use, then if its compromised you generate a new one. That approach is pretty simple and efficient. We use that with hubspot and other saas software. The extra layer like linkedin where you have an api key, then do an openauth authentication is definitely more than needed.
If you take this shared secret approach, that would allow someone to do the iframe embedding as well I think.
Would it be useful if you could achieve single sign on without needing any code change in your application?
"Real" SSO would require code in your application to provide cryptographic guarantees that the user really was authentic. However, given the relatively low sensitivity of the information involved in the ideas portal, I wonder if we could offer a weak form of SSO. It would provide convenience so users didn't need to sign in again, but it would not provide any security guarantees. e.g. a malicious user could publicly disclose the URL allowing anyone to access the ideas portal. A malicious user would also be able to impersonate other users.
In many cases the simplicity of integration might outweigh the negatives. Would it work for you?
This is closely related the iframe option I just noticed. That would be an appropriate solution to our issue if we can host it within our app - you probably need the same security mechanism to do the iframe as the sso anyway.
What we would need is really some basic protection so only people who are users of our site can access it via a link from our application. We have many people with gmail or other emails so we can't filter by domain. The simplest thing would be to allow an access key (simple guid) to be defined, so our site would pass the name, email and access key, which would indicate that the user can be logged in and an account created if it doesn't exist.
It's possible someone could share the link with the access key, but it would stop someone from just finding the site if public, or preventing sign up if private. Then we can always regenerate the key and update our app if the key got compromised.
Any kind of simple mechanism that allows someone to access and be recognized without having to enter name/email would be fine. Without this, Aha really isn't a useful tool for us.