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.
TVMIA,
--Bill