Cloud Blog

iOS Device Policies in WSO2 Device Cloud Part 1: Enforcing Restrictions

Today, many organizations allow employees to bring their devices to work, which introduces new risks to corporate data as people typically use their devices for work purposes. To minimize the risk of exposing corporate data to unintended parties, organizations may want to manage the devices of their employees and enforce rules or policies on what each user can do with their devices. WSO2 device cloud is capable of managing devices and enforcing strict policies on devices to increase the information security of an organization. In this series of blogs, we’ll explore the policies that are available for iOS devices in WSO2 Device Cloud. First, let’s take a look at device restriction policies.

Passcode Policy

This is one of the most common policies that provide an OS level security to a device. With the passcode policy, administrators can make sure that every user has a strong passcode for their devices and make the user adhere to the rules defined by the administrator when setting up a password. When a passcode policy is set on a device, the device will prompt the users to add a passcode that adheres to the policy.

Restrictions

Restrictions allow the administrator to restrict the devices from performing some actions. For example, the administrator may need to:

  • Disable users from using their cameras within the organization.
  • Disallow iCloud backup to stop any corporate data being backed up to iCloud.
  • Allow voice and video conferencing.

There are over 50 restrictions that iOS restriction policy provides and these policies allow an administrator to have fine grained control over what each use can and cannot do with their iOS devices.


In our next blog, we will explore policies for pre-configured networks and communication.

How API Gateway constructs URLs and translates them to backend calls

The URLs that your APIs have when hosted in API gateway and exposed to the world are different from the URLs of the backend services. Today we will explain how API gateway translates the calls that it gets into what it invokes and how each piece of that URL can be modified.

We will be looking at a simple case of one-to-one translation when you just want to pass parameters and values to the backend as they are (you can modify them on the fly too – see some links at the end of the post):

  1. API subscriber invokes something like apis.example.com/directory/1.0/users?identifier=123,
  2. If apis.example.com is associated with your organization in API Cloud, the API gateway receives the call,
  3. From the API context (directory) and version (1.0), the gateway identifies which API it should be calling,
  4. The gateway “knows” the Production Endpoint for that API (or Sandbox Endpoint if that is what is being invoked),
  5. It takes that endpoint and appends the resourceparameters, and values to it.
  6. The gateway then passes that call to the backend.

Let’s look at the elements of the API URL that the subscriber is invoking in the cloud:

  • API gateway URL (in our example, apis.example.com) is the URL part that all your APIs will share. By default, API Cloud will assign you something like gateway.api.cloud.wso2.com:443/t/orgid/ – but you can easily change it to your own custom URL,
  • Context is the URL path of that specific API (in our example, directory). All the REST resources of this API will share it (for example, directory/users directory/books, directory/groups). You specify that value on the first step of API design, right after the user-friendly name:

  • Version is defined on that same step, right after the Context. If you do not want the version to be a part of your API URL at all, you can select the Make this the default version checkbox on the 3rd step of API editing:

  • Resource is the HTTP noun that you use (users, books, groups, and so on). Just provide the name on the first (Design) step of API design in the URL Pattern box, select the HTTP methods you want to allow for this resource, and click the Add button:

  • Path parameters (for example, /users/123) get added in curly brackets right within the URL Pattern box (for example, /users/{identifier}). Query parameters (for example, /users/?identifier=123) get added by expanding the API resource that you just added, typing the parameter name in the Parameters box, and clicking the Add Parameter button (see the picture below). You can then change the type of that parameter from query to header or formData.

  • The values of the parameters will be provided by API users when invoking the APIs,
  • Finally, we need to specify the backend base path for the API. On the second step of API design (“Implement”), select the Managed API option, and type the backend URL into the Production Endpoint edit box:

See also: If you want to also do some call transformations on the fly, here are a few additional posts on how to do that:

Authenticate End-Users for APIs: LDAP, AD, SAML, Database, Web-Service

APIs are often the backbone of the functionality used by mobile and web-applications. These applications in their turn often need to “know” end-user identity to provide personalized service: end-user-specific data, permissions, access, and so on. How do you get API Gateway to verify that the user is who she claims she is, let her use the API, and pass her identity to the backend?

We have now made it easy with Configure / External Users / API Consumer Authentication configuration screen:

The following options are available:

1. Using existing SAML Identity Provider

Use this option if your application is already SAML-enabled, authenticates with an existing SAML provider, and now just needs to use that SAML token to access the APIs.

The configuration dialog box will ask you for the SAML provider details. Once the configuration is applied, your application will be able to use the SAML Grant Type to get API access OAuth token. When that token is used, JWT with the user identity information will be passed to the backend.

See our SAML Grant Type documentation for details.

2. Directly connecting to an LDAP userstore

If your LDAP directory is visible to API Cloud (for example, you have set up a VPN connection):

  1. Select the Connect your LDAP User Store option,
  2. Clear the Outbound agent configured checkbox,
  3. Specify LDAP connection parameters.

Once the configuration is live, your application will need to use the Password Grant type to get the OAuth token. API Gateway will verify the end-user identity against the LDAP and generate a personalized OAuth token. Each time the end-user accesses the APIs, the gateway identifies the user and passes the user details to the backend via JWT.

See this documentation for details.

3. Connecting to LDAP/AD via Identity Cloud

If your LDAP or Active Directory (AD) is behind a firewall and you do not want to have direct connectivity with it you can use WSO2 Identity Cloud to connect to the directory:

  1. Sign-up for WSO2 Identity Cloud and use its agent to hook up the directory,
  2. In API Cloud’s Configure / External Users / API Consumer Authentication screen, select the Connect your LDAP User Store option,
  3. Leave the Outbound agent configured checkbox selected.

This is sort of a combination of the previous two cases: API gateway is using Identity Cloud as the identity provider to authenticate the user. After which a personalized OAuth token is granted.

See this documentation for details.

4. Verifying user identity via a custom web service

If your end-users are stored in some sort of database or another system that you can expose via a web-service – select the Connect your RESTful Authentication Service option and provide the connection details.

By default, API cloud will be trying to authenticate end-users with a POST invocation with the following JSON payload:

{
	"credentials": {
		"username": "userx",
		"password": "mypass"
	}
}

If the end-user record is valid, API Cloud expects a response with the following JSON:

{
	"response": {
		"status": "true"
	}
}

These formats, however, can be changed using the configuration dialog box.

If the verification is successful, personalized OAuth token is granted for API access, and each API invocation comes with the user-specific JWT token.

See this documentation for details.

 

API Cloud is a powerful and flexible API management system. Should you have any questions, just click the Support menu and we will be happy to help.

Categories

Recent Posts

Most Popular Posts