Hi Abhishek,
When integrating with Liferay, Alfresco is configured to use the external authentication system, which is basically a way for Alfresco to allow authentication to be delegated to an external system - basically if that system gives Alfresco a username, Alfresco will treat that user as authenticated.
To do this, as far as I know, by default Alfresco expects a header to be supplied on the request containing the user id of the authenticated user - unless you've changed this in the external authentication subsystem properties, this will be the header "X-Alfresco-Remote-User". If this header is present and contains a user that Alfresco recognises, then you get logged in - otherwise login page.
Normally (I think), when Share is running as a portlet in Liferay it generally gets the screen name from the remoteUser value of the current request (from the portlet's user-principal-strategy: screenName). It then set's the "X-Alfresco-Remote-User" header on all requests from the Share running within Liferay to Alfresco, thus meeting the external authentication requirements.
In your case, it sounds like Share is not sending the correct header on the request to Alfresco, so Alfresco is redirecting for authentication. It may be that because of the involvement of CAS in the mix here that the remoteUser value is unavailable to the share portlet for some reason.
Another possibility is that the header is being sent but the username being included on the header doesn't match what Alfresco expects.
I would suggest next steps to take would be to verify whether or not the header exists on request from Share to Alfresco and whether it contains the right value. Possibly use a network analyser like Wireshark if Liferay and Alfresco are running on different systems, or if you can, attaching a remote debugging session will allow to see a lot. Classes to look at would be org.alfresco.web.site.servlet.SSOAuthenticationFilter on the Share side and org.alfresco.web.app.servlet.DefaultRemoteUserMapper on the Alfresco side
Regards
Steven