Vibrant discussion about CSLA .NET and using the framework to build great business applications.
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?
Rocky
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.