Csla has a CslaPrincipal and CslaIdentity, fact. They can be overriden and customed and finally the ApplicationContext.User is set with an object implementing IPrincipal.
But what if the Wcf Service has to be an "Relying Party" as part of an WIF solution?
I have the requirement to set up Federated Authentication using IClaimsPrincipal and IClaimsIdentity. So far so good, but i don't want to put any knowledge to decrypt the Issued Token (a GenericXmlSecurityToken) to a ClaimsPrincipal.
If the client application doesn't has this knowledge then i think csla authentication fails, please correct me if i'm wrong. The authorization checks are done in the 'smart objects' client side and server side. IsInRole etc can't execute without knowing the ClaimsPrincipal. It should be possible, somehow, that the client only has an Issued Token and use that to call the custom WcfPortal with a WS2007FederationBinding
I'm thinking to go around this issue by creating a webservice to convert the Issued Token to a IClaimsPrincipal so that the knowledge to decrypt is on the server side, but this might be a security issue!
This comes down to the type of experience you can give your user. If you can't check authorization rules on the client then you must allow the user to do everything and then when the server detects that they did something illegal you can throw an exception.
Terrible experience, but if you won't put at least a copy of the user's roles or claim data on the client, what can you do?
What i would recommend trying is what we do in Silverlight, where a copy of the user's real identify info is used to create a principal for the client. That allows client side authorization to work.
Or maybe i am missing the point of your question?
The problem is that i don't know if it's a security issue to allow someone to 'decrypt' the Issued Token to a ClaimsPrincipal.
I think it's hard enough to get the token from an STS, maybe that's secure enough and i should face away :)
Or is it possible to set the ApplicationContext.User server side? If that's the case then there might not be a security issue after all.
Or as u recommend, a webmethod returning (a lightwight copy of) the claims principal with just the IsAuthenticated property set and containing the roles.
PS: Have u looked into ClaimsPrincipal and ClaimsIdentity, as it's going to be more standard in .NET 4.5
Thinking this over i think there isn't even a problem at all, since i can use the issued token to get thru the dataportal and just fetch (a lightwight version of) the principal just like any other business object. Now i just need to continue with my custom WcfPortal and don't be afraid of exposing additional information.
Your first answer was correct, but i do wonder if u looked into .NET 4.5 :)
I have spent virtually no time on .NET 4.5 yet, no. The focus has been on mono support, then "Mango", and now Silverlight 5. .NET 4.5 will be the focus after we're done with the 4.3 release.
I'm glad csla is 'extensible' and i can hook into the dataportal and implement my own logic around it.
I think the DefaultPortalProxyFactory is good enough and i only need to define an AppSetting in the client "CslaDataPortalFactory" to register my own dataportal proxy in which i can override the GetProxy method to return a channelFactory.CreateChannelWithIssuedToken(token);
Then I just have to figure out how to make the token available to the proxy instance.
Do you maybe have some sample code that you can share? I'm developing a WPF application that uses Azure ACS. I'm using an embedded web browser control to display the login screen and do the redirects. When all the redirects are finished, I'm getting the security token from the embedded web browser. I'm not quite sure how to construct a principal/identity from the security token, so any help would be greatly appreciated.
It depends if have a multi-tier application, using CSLA wcf proxy having a wcf-service 'server-side'. In that case you have several options:
Make the service 'claims-aware' by making it a relying party
For this you need some WIF and CSLA fundemental knowledge to understand it, it is the way i prefer.
This isn't easy, you will need to learn how WIF works and integrate it into CSLA.
I have code, but it's copyrighted by my company....
Keep the service simple by just using a standard binding.
This would require you to 'read' the claims on the client and construct a csla principal when logging in.
Copyright (c) Marimer LLC