Page tree
Skip to end of metadata
Go to start of metadata

This document is meant to describe the high level steps that should be taken for securing the generic end points used by Aptify Web style applications. The sub- pages under this document describe what's available today to accomplish these goals in Aptify Web application.

Similar kind of actions can be taken for Aptify e-Business Services as well.

This document is not an end all-be all list of what you need to do to accomplish this. This is not a task that can be applied generically to each application. You are going to need to think about the needs of your application and how it makes sense to limit access to certain pieces of data. Testing that security is applied correctly should be a part of every build. It is not a 'one and done' effort. It is something you should be constantly thinking about as your application evolves.

  1. Create your Application Pool Identity and the appropriate group for your application.  
  2. Create your Service Application Record. Limit your authentication providers to only have the methods you actually need. Ensure that 'Restrict Views' is checked for your Service Application record. This forces you to explicitly list what views and entities should be accessible through our generic end points and reduces your attack area significantly.  
  3. Create your Service Application Entities for your application. Default it to Deny All. Explicitly add your entities back in.
  4. Create records for Service Application Views if your application calls views. Think critically about the views. Are you filtering data based on the current person? If so, that should be a server side parameter. What other prompt parameters does your view use? If I call it manually with values other than what's intended, am I allowed to see data I should not?
  5. Create records for your Service Data Objects. Think about their parameters in the same way you did for Service Application Views. Additionally, do you know why you are allowing all your SDOs to be executed? Some may be called due to stock client side GE plugins. Are they necessary for your application? If not, does Aptify provide a way to disable them so they are not called?
  6. Ensure you are only exposing the controllers your application needs to call. If you aren't working with attachment data, don't stand up the attachment end point. If you aren't using space threads don't add the space thread controller.  
  7. Take stock of what operations you are performing through the client side generic entity. For web user applications we do not have a good way to restrict record level access. If you want to limit writes to the Person entity such that the authenticated user can only update their person record, you need to write an Authorization Plugin to accomplish this. A Database Object that's a Function can be used to answer common security questions. Typically you want two versions of the same function. One to answer single record access questions that can be used to answer the question of 'does the user have access to record 1', and one for table level access that answers the question of 'what are all records this user has access to for this entity'. Having two functions allows for the best performance in most scenarios, as using the single record access function to answer table level questions will not be performant.
  • No labels