I am using the spring
org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean to
make the remote call. There is no additional session management is being
used. I can print the logged in user correctly before making the remote
service call.
I am using a
org.springframework.security.cas.authentication.EhCacheBasedTicketCache
for both applications. I am not sure if the problem lies there.
*applicationContext-security.xml
*
<bean id="casAuthenticationCommonsHttpInvokerRequestExecutor"
class="my.package.CASAuthenticationCommonsHttpInvokerRequestExecutor"/>
<bean id="userServiceHttpClient"
class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl"
value="${ds.server.url}/service/http/userService.service"/>
<property name="serviceInterface" value="my.package.UserService"/>
<property name="httpInvokerRequestExecutor"
ref="casAuthenticationCommonsHttpInvokerRequestExecutor"/>
</bean>
public class CASAuthenticationCommonsHttpInvokerRequestExecutor extends
CommonsHttpInvokerRequestExecutor {
protected final Log log = LogFactory.getLog(getClass());
@Override
protected PostMethod
createPostMethod(HttpInvokerClientConfiguration config) throws IOException {
PostMethod postMethod = super.createPostMethod(config);
try {
CasAuthenticationToken auth = (CasAuthenticationToken)
SecurityContextHolder.getContext().getAuthentication();
// debug current user
log.debug ("Current User = "+ auth.getPrincipal().toString());
String targetUrl = postMethod.getURI().toString();
String proxyTicket =
auth.getAssertion().getPrincipal().getProxyTicketFor(targetUrl);
postMethod.setQueryString("ticket=" + proxyTicket);
} catch (Exception ex) {
ex.printStackTrace();
log.error("### Error introducing credentials. Reason: " +
ex.getCause());
}
return postMethod;
}
}
Regards
Kiran
On 9/8/11 11:44 AM, Andrew Petro wrote:
> > all audits still show changes as 'user1' on the Data service but
> portal correctly shows as 'user2'.
>
> Why is your portal still accessing these data services as 'user1' when
> it is now servicing a session for 'user2'? Shouldn't it have used a
> PGT associated with user2's session to obtain a PT on behalf of user2
> to access those services, authenticated to those services using that
> PT, and thus the services should reporting these accesses as in the
> name of user2?
>
> *That* is a problem, and CAS single sign-out isn't the solution to it.
>
> I'd guess that your portal is creating sessions with these backing
> services and somehow decided to continue to use those sessions despite
> a different user having logged in. Sharing across multiple user
> portal sessions of HttpClients or Http connections or whatever
> underlying abstraction there is between portal and backing data
> services is a problem.
>
> Andrew
>
>
> On 9/8/2011 9:58 AM, Tropigeek wrote:
>> Hello
>>
>> I have two CASified applications configured for portal and data
>> services deployed on tomcat. Both applications have
>> /SingleSignOutHttpSessionListener /in the web.xml and
>> /SingleSignOutFilter/ and /requestSingleLogoutFilter /configured in
>> the applicationContext-security.xml
>>
>> I am making proxy requests from portal to the data services and use
>> the SecurityContextHolder to get the user information for auditing
>> purposes. Everything works well. When 'user1' logs in to the portal
>> application and access remote service. Audit shows that user1 made
>> changes to business objects.
>>
>> Problem is with Single Signout. When 'user1' logs off, only the
>> portal is logged off. I can see the logs on the CAS console that its
>> deleting the TGT entries. On the portal console also I see log off
>> messages. But no log off is seen on the Data services console.
>>
>> Close browser and log in as 'user2' and all audits still show changes
>> as 'user1' on the Data service but portal correctly shows as 'user2'.
>>
>> Why is CAS not logging off my remote services ? What am I missing?
>>
>> Regards
>> Kiran
>>
>>
>>
>>
>>
>>
>> --
>> You are currently subscribed [email protected] as:[email protected]
>> To unsubscribe, change settings or access archives,
>> seehttp://www.ja-sig.org/wiki/display/JSG/cas-user
>
> --
> You are currently subscribed to [email protected] as:
> [email protected]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
