You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Solutions for authenticating web APIs is an important topic and there are many solutions available. Some methods are easy to implement locally and others require outsourcing to a security solution provider. The SRP HTTP Framework ships with a few pre-built authentication methods so developers have an out-of-the-box solution. However, the authentication framework is extensible. Developers can add to or modify it as needed. Alternative ways of handling authentication will be covered in separate articles.

Authentication versus Authorization

The terms authentication and authorization are sometimes used interchangeably and they seem analogous. While they are related, they do mean different things and it is important to understand those distinctions.

Authentication is the method to confirm a user's identity (i.e., Are they who they say they are?). This is often handled through a username and password but it can be handled in various other ways (facial scanning, fingerprint reading, responses to text message on your cell phone). The purpose of authentication is to grant or deny the user access.

Authorization is the method to identify a user's permissions (i.e., What can this user do?). Sometimes these permissions are referred to as privileges or scope. Permissions are often configured through a user management tool.

To use an analogy of someone entering an office building, authentication should be used to grant a visitor access to the lobby, but authorization should be used to identify which hallways and office rooms that are accessible to the visitor.

Some security methods combine the two, such as OAuth. Other security methods just assume an authenticated user is fully authorized to access everything. The pros and cons of these methods is worthy of another article. The main takeaway here is to understand the caveats of each implementation and to avoid the mistake of treating authentication the same as authorization (or vice-versa).

Enabling Authentication

Regardless of which authentication method(s) will be used, the Enable Authentication option needs to be set. Otherwise, the SRP HTTP Framework will automatically authenticate each request as valid (although any internal authorization logic will still work as normal). To set this option, run the HTTP Framework Setup form (e.g., EXEC NDW_HTTP_FRAMEWORK_SETUP from the System Monitor) and then click on the Authentication menu to open the Authentication Options page. Make sure the Enable Authentication? box is checked:

Using HTTP Basic Authentication

The SRP HTTP Framework provides built-in support for HTTP Basic Authentication. This is a simple username and password method for identifying the web user. It conforms to the stateless constraint of REST because it assumes that each and every request will use HTTP Basic Authentication. Thus, this does not inherently provide a way of "logging in" to the web application. Because the user credentials are passed included in the HTTP request, it is highly recommended that this form of authentication only be used through an encrypted transmissions (i.e., HTTP over SSL or HTTPS for short).

In addition to the Enable Authentication option being set, the Enable HTTP Basic Authentication option also needs to be set. This option is immediately below the Enable Authentication option on the Authentication Options page. We'll review the sub-options for this later.

Unless changed by the developer, user credentials are maintained in the WEB_ACCOUNTS database table. To manage web accounts just run the Web Accounts form (e.g., EXEC NDW_WEB_ACCOUNTS). To create a new user you can enter in an ID and populate the rest of the fields manually or you can click on the New Account menu option. This will dynamically generate an ID and prepopulate other fields for you:

The Name field must be updated (it's a required field in this form) and the Save Account menu option clicked. We'll review the other fields later.


  • No labels