Hi Gwowen,
If you want to understand a little more about what happens under the hood, there are a few elements at play. There are two MAIN pieces for this.
1. OpenSSOFilter
2. OpenSSOAutoLogin
The filter by default in Liferay is set to enabled, and the OpenSSOAutoLogin is part of the listing for the auto.login.hooks. If OpenSSO is enabled (either through properties or the control panel) then the OpenSSOFilter will run. Assume for the moment that your entire site is protected. The OpenSSOFilter will detect that you are trying to access a protected resource and will route you to the "login url" you defined in your settings (again, properties or control panel). An alternative to this, for the record, might be to use a J2EE agent or a WebAgent on the proxy to protect specific resources (urls). Either way, the point is the user is routed to the SSO (lets just say OpenSSO for simplicity) server.
Inside the OpenSSO server a realm will have been created. The realm will encompass applications that are all trusted. Normally this part, I beleive, is called the Identity Provider. So is you have a Timesheet tool, a Vacation Tool and an Expense tool all as separate applications, you can add them to the same "bucket" so that authenticating for one automatically authenticates you for the others. As you know, the authentication is tied to a directory store where the users details are stored. So you user is on the OpenSSO web page and signs in successfully.
They are routed back to Liferay at this stage with their cookie proving that they have authenticated. The OpenSSOFilter detects this and the user now goes into the "auto.login.hooks" chain. Eventually they hit the OpenSSOAutoLogin hook. This hook will check for the cookie and then communicate silently over http (REST type services) with the OpenSSO server and validate the token as well as retrieve some mappings. The class will then determine whether or not a user with the same attribute values exists in Liferays database. This is important because although you gain access to Liferay as an endpoint from authenticating with OpenSSO, Liferay itself needs to authenticate you so that you have a security context in the portal. If the user is not found Liferay will automatically create a new user account using the LDAP mappings to create the record. Once the user is created, then you are signed into the portal.
This last step is important. If there is a problem with the mappings, then the user cannot be created in which case even though you pass authentication with OpenSSO, you won't get into the portal.
Once in the portal the user clicks links to go to the the expense tracker for example. That request travels there with the same OpenSSO cookie. The expense tracker has it's own filters/logic that will detect the cookie, communicate with the OpenSSO server and then grant access or not. The end systems, as a matter of interest, are referred to as "service providers". So the service providers communicate with the identity provider in order to validate whether or not you are authorized to access a resource.
