Skip to Main Content

Share your product feedback

Status Shipped
Categories Ideas
Created by Guest
Created on Sep 9, 2014

Use SSO for Idea submission

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.

  • Attach files
  • Scott Kendrick
    Reply
    |
    Jan 2, 2015

    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.

  • Richard Harrison
    Reply
    |
    Jan 2, 2015

    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.

  • Admin
    Chris Waters
    Reply
    |
    Nov 11, 2014

    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.

  • Guest
    Reply
    |
    Nov 11, 2014

    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.

  • Admin
    Chris Waters
    Reply
    |
    Nov 7, 2014

    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.

  • Shelley Cryan
    Reply
    |
    Nov 7, 2014

    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? 

  • Guest
    Reply
    |
    Nov 6, 2014

    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.

  • Admin
    Chris Waters
    Reply
    |
    Nov 6, 2014

    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? 

  • Guest
    Reply
    |
    Nov 6, 2014

    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.

  • Guest
    Reply
    |
    Nov 6, 2014

    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.