How does the security work in DevForce 4 SL?

 

b) Authentication is performed via implementation of the IEntityLoginManager interface.  This effectively leaves how the authentication is accomplished to the developer. The credentials passed into the Login method must be an implementation of ILoginCredential, and the return must be a System.Security.Principal.IPrincipal, but the concrete types involved can be of your choosing.  The IPrincipal interface is supported in Silverlight, although WindowsPrincipal is obviously not.  DevForce only cares about the interfaces and not the concrete types.

 

c) The IEntityLoginManager is implemented on the BOS (the ASP.NET project), so an EntityManager.LoginAsync() call from the Silverlight client is sent to the Login method of the interface implementation.  The IPrincipal returned is saved to the SL client.   Unfortunately, we currently don't expose that within the client application (in a standard .NET application the Thread.CurrentPrincipal is set), but in server-side events and interface implementations the IPrincipal is usually passed and the Thread.CurrentPrincipal is set, so your code can query the user role.

Basically, you collect whatever credentials you need on the client (e.g. user name and hash of the password) and these are passed to the server where there is a hook for you to implement your authentication logic (e.g. database table, windows domain controller, ldap).

 

Once authenticated, your session is digitally signed by the server and any requests from the client can be checked for authorization by the server behind the firewall (which can include role based security checks).  Even if the client is compromised (even deliberately by the administrator of the machine), the server can still perform authorization before allowing a request to go through.

 

SSL3 provides the encryption for the communications channel to keep everything private.