FlexClient.getUserPrincipal() returns null

[amiladomingo]

Hi,

I want to get the user principal for a specific Flex client, i get the Flex client with following code,

FlexClientManager flexClientManager = messageBroker.getFlexClientManager();
String[] clientIDs = flexClientManager.getClientIds();

for (String ID : clientIDs) {
	FlexClient flexClient = flexClientManager.getFlexClient(ID);
}

but when i do flexClient.getUserPrincipal(), it returns null. but i am able to get the User Principal with following code,

		
UsernamePasswordAuthenticationToken principal = 
(UsernamePasswordAuthenticationToken) ((HttpFlexSession) flexClient.getFlexSessions().get(0)).getUserPrincipal();

is this the best way to do this? Any suggestions?

[amiladomingo]

So when you do per-client-authentication="true" only flexClient.getUserPrincipal() returns the Principal.

<flex:message-broker>
	<flex:secured per-client-authentication="true" />
</flex:message-broker>

Default it is false and when it false you can only find the Principal in the HttpFlexSession of FlexClient

[amiladomingo]

Making per-client-authentication="true" i face another problem

Users in my application should be able to log in the application through multiple browser on same machine, and when per-client-authentication="false" user is not able log into the application using multiple internet explorer 8 browsers.

When i change it to per-client-authentication="true", it allows the user to log in to the application concurrently without any errors. but this change makes the spring security context user "Anonymous". i found below text on Spring-Flex documentation,

Enabling per-client authentication will cause the Security context to no longer be stored in the session between requests and thus will prevent the use of any Spring Security filters that rely on the Security Context being available in the session, but the authentication and authorization integration will otherwise work as expected. (See the BlazeDS docs for further information on the difference between per-session and per-client authentication.)

My requirement is,

1. User should be able to log in with same creadentials more than once (number is configurable)
2. SecurityContextHolder.getContext().getAuthenticati on() should return the current principal

Appreciate your help

[jeremyg484]

I wouldn't expect the Authentication to be "Anonymous" unless you're checking at some point in the call stack before the MessageInterceptor chain is applied.

At what point in the request are you calling SecurityContextHolder.getContext().getAuthenticati on()?

[amiladomingo]

At what point in the request are you calling SecurityContextHolder.getContext().getAuthenticati on()?

I'm calling after all the filters are applied. In a normal middle-tier class.

SecurityContextHolder.getContext().getAuthenticati on() doesn't get null if i don't do following (marked in red)

<flex:message-broker>
<flex:secured per-client-authentication="true" />
</flex:message-broker>

When i do above, PerClientAuthenticationInterceptor gets called in somewhere in filter chain and inside the postProcess() method it does SecurityContextHolder.clearContext();

In spring flex integration reference it says http://static.springsource.org/sprin...l/ch04s02.html

The per-client-authentication attribute turns BlazeDS's per-client authentication mode on when true, and defaults to "false" if not specified. Enabling per-client authentication will cause the Security context to no longer be stored in the session between requests and thus will prevent the use of any Spring Security filters that rely on the Security Context being available in the session, but the authentication and authorization integration will otherwise work as expected. (See the BlazeDS docs for further information on the difference between per-session and per-client authentication.)

[jeremyg484]

Is that normal middle-tier class invoked as the result of a Flex remoting request? If so, the Authentication definitely should not be null and should not be Anonymous. But as the docs mention, that is a fairly limited scope.

[amiladomingo]

Yes it comes as a Flex remoting request but since per-client-authentication="true" security context doesn't store the authentication between request.

The reason i had to do per-client-authentication="true" was, we have a requirement to allow the user to log in to our application with more than one internet explorer 8 browsers in same machine using same credentials.

Is there a better approach you see?

[jeremyg484]

Yes it comes as a Flex remoting request but since per-client-authentication="true" security context doesn't store the authentication between request.

That is correct, *but* the Authentication gets set for the request in the PerClientAuthenticationInterceptor so that you should have access to it within the scope of the remoting request. It should not be returning null if you invoke SecurityContextHolder.getContext().getAuthenticati on() within that scope.

Is there a better approach you see?

Well, I suppose the bigger question is whether it is truly necessary for the two browser instances to have separately tracked logins, rather than as part of their shared session. (Two separate browser windows/tabs pointed at the same application at the same time equates to a single shared HTTP session.)

The approach that I think is more commonly used is to check when the client starts up whether the given client already has an authenticated session, and opt not to show the login screen in that case.

To do this, you just need to provide a remote service that checks for and returns the Authentication if found, invoke that as soon as the application loads, and conditionally display the UI based on the result. We provide an AuthenticationResultUtils class that is designed to aid in implementing the server-side piece.

[amiladomingo]

It should not be returning null if you invoke SecurityContextHolder.getContext().getAuthenticati on() within that scope.

I do invoke this within the request scope. but it returns null

The approach that I think is more commonly used is to check when the client starts up whether the given client already has an authenticated session, and opt not to show the login screen in that case.

Thanks for the suggestion, will talk to the client and see