> I thought that cache refresh was the mechanism used to sync external LDAP users (i.e. Active Directory users) to the Gluu LDAP server (openDJ) so that when Gluu is used for authentication, it then had access to all the information needed to log in users; so it would use local openDJ for the authentication rather than needing to contact the external LDAP for authentication.
You are correct about the first half, but not about authentication part. The purpose of CR is indeed to aggregate and prepare (with CR interception scripts) attributes from a multitude of sources (only LDAP directories by default, but that may be extended in the future). But in most scenarios where CR is used actual authentication still must happen against one of the backends you've got these attributes from. One reason for that is the fact that passwords usually are not fetched (and for some backends, like Active Directory, they cannot be fetched at all, not via LDAP interface, at least).
So usually the next step after you got user data into Gluu's own directory is to configure oxAuth to use backend for authetication. Unless you are trying something really unique. Meaning you are not forced to use backend, you could use some other means and assign passwords to all these user entries CR created for you, and use internal LDAP for auth (i.e. by changing nothing on the "Manage authentication" page), but that's not something many organizations use. It's just more convenient to have a central service where all your internal authentication happens.
The purpose of CR is to aggregate and process attributes, so it could serve them then without consulting the backend on each SSO request (and there could be thousands of such per minute). Like, authentication happens just once, and then session is created for this user at Gluu, and each subsequent SSO request will be handled from Gluu's internal db of user's attributes, which values may be significantly different from values in backend (due to logic implemented in some CR scripts)