Use case: I have 1 API, with 2 Endpoints, one is /heartbeatOauth and the second one is /heartbeatClientCredentials. I want to be able to apply the oAuth policy for the first endpoint, and for the second endpoint to apply the Client Id enforcement.
Is there a way to do that?
You can achieve this using URI regex in policy settings. More details you can find in this documentation: policies-resource-level-config-uri-regex
Related
I need to develop a REST API for a new user registration form which consists of 2 steps. Step 1 validates email and password requirements. The data gets saved into the database on Step 2 after the user specifies valid country and region. What is the recommended approach in such scenarios? Using different endpoints for step 1 and 2, like /users/password and /users/location? Using a single endpoint, but having some info about the current step as part of the Dto? Anything else?
Hi you can use both of the options i my self used both of them but in my experience using a multi endpoint is more maintainable. And also it good match for single-responsibility principle (SRP)
Suppose you have two endpoints in a mule application and you want to restrict access of one endpoint to a particular client application and make only another endpoint available for access.How can you implement this?
You can use a custom policy to achieve the same. So far, there is no OOTB policy available for the same. The other thing you could do but is not as elegant a solution ( this is also applicable in case you are not using API manager aspect of the platform) is making use of filter in the Mule application (Mule3) and validation module in Mule4 whereby if the incoming request (for a given resource/HTTP verb combination) has a particular clientId you drop/filter that request while you let others go through..
I have followed the tutorial for enforcing policies on API calls
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
It wasn't easy but I got something up and running. I can change access to different endpoints of an API depending on the user's role.
I have a question. Here's a fictional setup to complete the tutorial:
API EduCollege, with endpoints /student/info and /staff/info (tutorial)
API Prison, with endpoints /prisoner/info and /staff/info (note that it's the same endpoint)
I write a policy EDUCollegePolicy that enables only those with role college_admin to access /staff/info (tutorial).
But there seems to be no way to restrict these college admins from accessing staff info of the prison!
The field resource only contains info about the endpoint.
Is there any way, using this setup, to limit by API?
Or does it maybe require a different JAR add-in, that would send a resource value set to API/version/endpoint instead of just /endpoint?
Oh, by the way: I couldn't set policies according to the endpoints provided in the tutorial. It doesn't seem that it's /staff/info, but I got it to work with regexp .*staff.*info.*. Not nice. I wonder what the actual resource sent from JAR to PDP is, I couldn't find it in any logs, including IDS logs (the IDS acts as PDP)
Using the okta API, we're trying to display a simple staff directory. Basically we want to list all active users in a particular group on a web page.
Seems like it should be super simple.
If I use the user endpoint, I can get all users and filter by status to be active, but I can't seem to filter by group.
If I use the group end point, I can get all users in a group, but I can't seem to filter by status.
How should I be going about this?
Edit: Added my api calls
method 1
$filters = 'status eq "ACTIVE"';
$c = curl_init("https://wvuf.okta.com/api/v1/users?filter=".urlencode($filters));
method 2
$c = curl_init("https://wvuf.okta.com/api/v1/groups/xxxxGROUPIDxxxx/users");
Unfortunately, this is not possible in the current version of the Okta API. As you've surmised, you can either GET all users with an ACTIVE status and then iterate through them to get the groups for each user or GET all users for a specific group and manually filter by status.
The latter method may be preferable because it will amount to fewer calls (assuming there are more users than groups).
The List Group members (/api/v1/groups/${groupId}/users) endpoint does not support the filter query param
https://developer.okta.com/docs/reference/api/groups/#group-member-operations
One suggestion is to do some client side filtering (eg using jq etc)
The ListGroupUsers method in the Groups API for Okta enumerates all users that are a member of a specified group.
Have a look at this tool I created for a project I am on, okta-admin, wraps up the Golang SDK for Okta in an easy to use CLI (which effectively invokes REST API requests...)
okta-admin groups listusers $groupId
I have added the ability to pass filter arguments supported by the API or endpoint as well as a jsonquery argument where you can perform searches or projections client side.
I have an API that provides an Account resource based on the authentication (login) that is supplied. As a user can only have one account, and can only see it's own account and not those of others, this API will basically be a single resource API in all cases.
So to keep things simple, I have this resource under the url accounts/ and when you access accounts/?username=dude&password=veryhard you'll get your account data (if you dohn't supply authentication you'll get a 403).
Now I wonder if this is RESTful. Also, you should be able to update your account info, and I wonder if PUT would be appropriate. In my knowledge, PUT should be done on a unique URI for the resource. Well, is this a unique URI for the resource? Generally a URI for an account would look like accounts/3515/ where 3515 is the account id. However, users don't know their account id. Also, there should be more ways to log in, instead of a username + password you should also be able to use a token (like accounts/?token=d3r90jfhda139hg). So then we got 2 URL's that point to the same resource, which also isn't really beautiful for a RESTful URI, is it?
So, what would be the most RESTful solution? Or should I not do this RESTful?
REST purists will consider that use of /accounts/ to obtain a single account is bad practice as it should specify a collection. Instead consider a key which cannot be mistaken for an ID, for example if your IDs are UUIDs then use a token such as 'me' so your URL is /accounts/me. This has the advantage that if later on you wish to obtain different account information, say for example you need to list users or you have an administration system using the same API, then you can expand it easily.
Putting username and password in the URL is also not pure REST. The query parameters should be directly related to the resource you are obtaining; commonly filtering and limiting the resources returned. Instead you should seriously consider using something like HTTP Basic authentication over an encrypted (HTTPS) connection so that you separate out your authentication/authorisation and resource systems. If you prefer to use a token system then take a look at oauth or hawk.
Finally, yes if you use PUT you should supply a full resource identifier. Given that it is very common for systems to read data before updating it the lack of ID won't be a problem as that will come back as part of the prior GET.
Yes accounts/?username=dude&password=veryhard is a correct REST URL.
PUT is used with an id if it used to update a resource, if you use it to create you must supply an ID. otherwise you use post to create a resource without id