2 Replies Latest reply on May 16, 2012 6:44 AM by cqlearner

    How does SSO work in CQ


      I'm working with CQ 5.4 and have to investigate how SSO would work. 


      We are planning on using CQ as our means of supplying clients with web functionality within their websites.  I see two scenarios, using our own page(s) (on a 'cq website we setup for each client) to which a client site user navigates, or a portlet within their site's page(s).  So far, I have been told by our team that clients' user's information has to be stored in a user profile within the CRX repo so that the personalization and analytics can be done.  I believe we plan on using one CQ instance for several clients, each of which could have thousands and thousands of users.  We'd like to have components that call backend services from scripts that can be used by any of the clients' users provided they have permissions (users of a particular type from client1 and other users from client2 have access to a script&OSGiComponent, but others do not).  I suppose this last bit could be done with ACLs, users and groups.


      I understand the general idea of SSO - only having to sign on once.  But I don't have a clear understanding of the mechanics, in particular, how it would work with the requirements I've just specified.  It seems from the documenation http://dev.day.com/docs/en/cq/current/deploying/configuring_cq.html#Single Sign On, that enabling SSO means that no authentication is ever done on CQ's side:

      "Single Sign On (SSO) allows a user to access all (or at least multiple) systems based on trusted authentication credentials (e.g. username and password) that are only entered once. This authentication is performed by a separate system, so CQ is no longer directly responsible. The third party system provides CQ with the (authenticated) user credentials; CQ trusts these credentials and checks what they are authorized to do (i.e. which resources the user is allowed to access)."



      Can someone give an example of the HTTP traffic that would be sent in a SSO CQ configuration (regular web site as well as a portlet example)? 

      How does CQ know who the user is? 

      Does CQ just take it as gospel that the user credential (eg username) is really the person that's contacting CQ? 

      Does there have to be a corresponding user with the same username defined in CQ as that of the credential?  What if there are naming conflicts?  (john from client1 and john from client2) - how can I have both john's represented in CQ? 

      Each 'website' in CQ has a different URL, right?, so would I have to configure something with each URL for a different 'authenticator'? ie. do I fill in these different URLs in a configuration screen?



      What's the 'BASIC' and 'AsIs' method?  It says I can use a RE - what's an example where I would use this?

      What do the credentials look like (AsIs and Basic)?

      Is the credential a username, or a token of some kind? 

      Is it always passed in every/each HTTP request the user makes to our website/portlet? 

      Is the credential ever validated by CQ somehow?



      How does all this fit into LDAP? 

      Does CQ have to be able to access any client systems like a client LDAP server? 

      Can I enable SSO for some clients/sites/portlets but not others in the same CQ instance? 

      Can I enable SSO to use LDAP for some clients and not for others in the same CQ instance?


      How do we make sure a user from client1 accessing a shared component (eg. script and/or OSGi bundle service) can't pretend to be a user2 or a user from client2?

      If I want to reuse code by reusing a component, and both user1 and user2 (from the same or different clients) can therefor both access the reused (hence shared) component (eg. an account balance service - script or OSGi service), how do I make sure that I can share the component code but not allow user1 to ask for the balance for user2's account?


      A few detailed working examples would help a lot I think.





        • 1. Re: How does SSO work in CQ
          justin_at_adobe Adobe Employee


          That's a lot of questions, but I'll try to answer at least some of them.


          In a typical SSO setup for CQ, the credentials are passed into CQ via an HTTP header (cookies and request parameters are also supported, but those are in my experience less common). This header is inserted into the request by a process external to CQ, either at the web or application server level. In other words, by the time the request reaches CQ, the credentials have already been validated and CQ is just receiving a userid. The syntax of this header can either be in the syntax defined for HTTP Basic Authentication, plain, or extractable by a Regular Expression. There's an example of a Regular Expression here: http://dev.day.com/docs/en/cq/current/deploying/configuring_cq.html#SSO%20Authentication%2 0Handler.


          When CQ receives a request with the header (or, again, cookie or request parameter) in the appropriate format, it assumes that the user has already been authenticated (or, in your words, CQ "take[s] it as gospel). CQ never sees the password or other credentials and would have no way of authenticating the user independently.


          It is almost always ALSO necessary for a CRX user with the same ID to exist in the repository. If you are using LDAP, then the LDAP LoginModule can create users (and groups) on demand. The way this works is that the LDAP LoginModule gets the login request, sees that the user doesn't already exist, and then populates the CRX user with information extracted from the LDAP server. If LDAP is not available, but some other user account storage system is, you can create a custom LoginModule to interface with that system to do the same thing (this is something I would recommend engaging with Adobe Consulting to do, but I'm biased being a member of Adobe Consulting ).


          In terms of your questions about multitenancy, one thing to keep in mind is that there is only a single namespace of users in CQ. If each "client" needs its own pool of users whose userids may overlap, then you will need to prefix (or postfix) the name in some way. How this works with your SSO system isn't clear to me, but I could imagine there needing to be some pre-processing of the userid passed to CQ in the SSO header to add this prefix. Similarly, how this would interact with a backend LDAP server (which presumably doesn't want to know about these prefixes) would also require some investigation.


          Hope this helps,


          1 person found this helpful
          • 2. Re: How does SSO work in CQ
            cqlearner Level 1

            Good explanition.  Can cq5 be integrated with PING which generates SAML token?  Can you describe how the flow would be? We are also using LDAP.