Using Authenticator server-side to Re-Login a Client-Side Session Key?

 

I'm updating the security code in one of our applications using the new Security stuff in 6.1.6.

 

As we use MVC controllers for certain complex server-side operations, I'm hoping to be able to pass (say) a SessionKey or a set of encrypted credentials from the AuthenticationContext on the silverlight client to the server, and be able to 'attach onto' that users session on the server.  This provides a small degree of security, but also allows better logging/auditing as we have access to the principal information.

 

Currently when I attempt this I receive an AuthenticationContext that has a LoginState == LoggedIn, but an unauthenticated principal.  This occurs whether I attempt to Login() with a valid guid session key, or a new one I've made up on the fly (ie, I can't tell from the AuthenticationContext whether the SessionKey is valid or not).

 

Interestingly, I wouldn't have expected a LoggedIn value for a dodgy sessionKey given I have allowAnonymousLogin set to false.

 

Is what I'm hoping to do possible?  Is there a better way?

 

Any operation we perform on the server as a result of an EM call from the client (ExecuteAsync() etc) does correctly pass authentication information back to the server, so no problems in the 'normal' DevFoce case :)

 

We host our own MVC Controllers for certain operations (For the same reasons DevForce provides RSMC functionality), however for historical reasons these Controllers (and the actions on them) already exist, so we haven't gone done the RSMC path.

 

However obviously we'd like to be able to keep making use of the client authentication info from the DevForce session, even though we've bypassed the DevForce WCF link back to the server (we're using Json if it's relevant).  Looking at the 6.1.6 API it looked as though we could pass the clients Session GUID to the controller, and then use the Authenticator.Login(Guid) overload to 're-activate' (if that's the best word) the clients session (and associated authentication information) within the scope of the MVC Action.

 

I'll get to work on a repro sample for you, but hopefully that's a better description of the issue we're currently trying to resolve.

 

Cheers,

Tim

I've attached a sample of the Login call that is not behaving as I'd expect.  I'm aware that RSMC would carry the auth context, however thats not a very enticing option TBH.   Any assistance you can give on how to make this work would be fantastic.

 

 

Cheers,

Tim

It appears we have a bug. From what I observed, Login(sessionKey) is going thru the LoginManager when it should not.

I have filed a bug and will keep you updated.

Regards,

Silvio.