DevForce Community Forum : Implementing Role-Based Security in a DevForce App

Answer:

The tutorial for Role-Based Security can be found in the Advanced rutorials under the name of "Role-Based Authorization".

The authentication methodology elucidated there provides the scaffolding upon which a role-based security implementation would be based. When you implement authentication in DevForce you provide a class that implements our IPersistenceLoginManager interface. That interface mandates a Login() method that is called by DevForce when your code invokes the Login() method on a PersistenceManager.

The Login() method you provide in your IPersistenceLoginManager class takes as parameters an ILoginCredential and a PersistenceManager; it returns an IPrinciple object. The IPrinciple interface mandates an Identity property and a boolean IsInRole() method that takes a string parameter containing a role name (e.g., "Admin"). IsInRole() must return true if the user identified in the IPrinciple object's Identity property is in the specified role; your code can then react in an appropriate manner. IsInRole() could, for example, do a database lookup to determine if its Identity user participates in the specified role.

In the implementation of the IPersistenceLoginManager.Login() method in the Security_Authentication solution, an IIdentity object is created by passing in a username and other items. IIdentity mandates a Name property which can be used for the UserName, which could be the mechanism to look up the user in the database. At that point it's just a matter of getting a Roles collection for the user, and seeing if the specified role is in it.[1]

Your (IPersistenceManagerLogin) Login() method returns an IPrinciple to the PersistenceManager.Login() method; the PersistenceManager.Login() returns a SessionBundle object. The SessionBundle object contains the IPrinciple object that was returned by your Login method. You can see this in the DoLogin() method in the LoginClientCore class in the Security_Authentication implementation. In that DoLogin() method, the SessionBundle object is passed to a SetLoggedInUser() method which ultimately sets the value of a static property of a CommonUser class that is available client-side. But that's just one example of what you can do with the SessionBundle object. The point is that it contains the identity of the logged in user for that PM; specifically, it contains an IPrincipal that represents that logged in user, and knows how to answer questions about role participation.

[1] The IIdentity object in the Security_Authentication implementation (called AppIdentity) also contains a UserId property distinct from the Name property, so that's an option for the database lookup as well.