Security

Security

Here are some security bits which we've covered in the current web/android app. Some of these will change/evolve as we play different features(offline login, multi server support etc,.)

Hearing more about the security requirements from lead/partner agencies would help a lot to understand what we can/cannot implement.

Information on Android security is documented here

Session/API Security:

• Support HTTPS transport (Mandatory in Production deployment)
• No passwords are stored in plain text in the system
• During first deployment/run, a one-time Session Secret is generated privately for that installation
• During login, the Session ID and a checksum is created. This is the Session Token
• The Session Token is encrypted with the privately generated Session Secret
• Only the Encrypted Session Token is saved in the Browser or API clients. The actual Session ID and other session information is never exposed outside the server
• The Cookie header is used for saving/retrieving the encrypted session tokens. Rather than using a custom header, we're re-using the Cookie header so that clients don't have to manually deal with token expiry management. API clients can easily save the encrypted session cookie in the Set-Cookie response header, and then include it in all subsequent requests in the Cookie request header

Authorization and Roles Framework:

• The hierarchy of authorization is: User --> Roles --> Permissions --> Ability --> Actions
• Action: Represents a controller action
• Permission: A fixed set of permissions are defined in the system. See app/models/permission.rb
• Ability: A class which maps this permission is allowed to perform these actions. This class is inside app/models/ability.rb
• Role: Created by users. Multiple permissions can be assigned to a role
• User: A User can be assigned multiple roles
• We are using the CanCan gem to implement Ability