The only thing I need from the Uber API is the price estimate function that requires at least the 'profile' scope that is of type general (thus I dont need to be have production rights).
But the authenticate function won't let me select the desired scopes and the dashboard wont give me the option to select them anywhere.
How can I solve it, is there a forum where I can ask?
Related
I'm only actually trying to use deeplinks, not even the api, but I can't find any way to get the product ID (uber connect) that I need without it, so I am attempting to get products.
https://sandbox-api.uber.com/v1.2/products
I am getting an the error "This endpoint requires at least one of the following scopes: ride_request.estimate" which I understand is because I have not gained scope access from uber.
(I did include that scope in the 0Auth request.)
It has been absolutely impossible to reach them. I filled out a form and it said they'd get back to me sometime but they are very busy.
An entire project is held up for hours over this detail and I'm really struggling for how to solve this. Is there a way to gain access or even make a sandbox request without that scope?
Or would someone be kind enough enough to run the call and let me know the response for [latitude]=-1.2741798[longitude]=36.791785
Thanks everyone.
i have a scenario where i want to restrict the user in keycloak
i have user
user can have access to multiple accounts
in multiple accounts, use can be Admin or agent (reader)
user
|
|
|-------account-1
| |
| |-------admin
|-------account-2
| |
| |-------agent
How can we map this in Keycloak with Policy, Permission, and role?
any reference document any example really helpful
also based from : Resources, scopes, permissions and policies in keycloak
From the answer of Andy, i have created one resource Account and role admin & agent.
created same policies as in example.
i am looking forward to add scopes (auth scope) and roles to JWT token how to map that part so that API gateway or service can verify further.
#changa, I've rewritten my answer based on our discussion. Hope this helps!
Let me first clarify some key areas before I answer. My main focus on the answer that you've linked was really on how to play around the Evaluate tool and I didn't really dive too deeply into some of the concepts - so let's do that :)
In Keycloak, you'll encounter Client and Authorization Scopes. For a formal definition of these terms please check out the Core Concepts and Terms in the Server Administration Guide, but simply put:
Client Scopes are scopes which are granted to clients when they are requested via the scope parameter (once the resource owner permits it). Note that there's also the concept of Default Client Scope but I've chosen to keep things simple. Furthermore, you can leverage protocol and role scope mappers to tailor what claims and assertions are present in the access token.
Authorization Scopes on the other hand are granted to clients after successful evaluation of the policies against a protected resource. These scopes are not granted to clients based on user consent.
The key differences between the two is really when and how a client obtains these scopes. To help you visualize all of this, here's a scenario:
A renowned martial artist called Bob authenticates via Keycloak
Bob get presented with a consent screen where he is asked to share his name, his fighting style and his age.
Bob chooses to give access to his name and fighting style but he declines to share his age.
When we inspect the token now, we would see the following (completely made up) entries for the scope attribute of the access token: name and fighting_style.
Additionally, let's assume that we've set up a couple of protocol mappers (e.g. User Attribute Mapper Type - there are a ton) to display the values for full name and fighting style via the following token claims: fighter_name and martial_arts when the two Client Scopes above are present in the access token. In addition to two previously mentioned scopes, we would also see something like fighter_name: Robert Richards and martial_arts: Freestyle Karate when examining the access token.
Side Note: Given the length of this answer, I've decided to skip this topic but please check out this awesome video at around the 7 minute mark along with the associated GitHub Project for more information. The README is pretty good.
Additionally, let's assume that Bob is mapped to a realm role called Contestant and a client role of Fighter and we did place any restrictions in Keycloak when it comes to sharing this info. So in addition to all the things mentioned above, we would see that information inside the token as well.
Needless to say, this is an oversimplification on my part as I'm simply setting up the stage for demo. purposes and there's much more information inside the access token.
Bob doesn't like how the tournament bracket is laid out as he's eager to fight the world champ as soon as possible, so he attempts to change his placement by sending a request against tournament/tekken6/bracket/{id}. This resource is associated with the scope bracket:modify. Additionally, there is a permission which associates the resource in question with a role based policy named Referee Role Required. If Bob were a Referee then he would be granted the bracket:modify scope but since he isn't, then he is denied that scope.
I've barely touched the surface when it comes to the inner workings of the Authorization process in Keycloak. For more information, check out this practical guide. You can do some pretty cool stuff with UMA.
Ok, so that's enough theory. Let's set up our environment to demo all of this. I'm using the following:
A realm called demo
A client called my-demo-client
A client scope called client_roles
2 users - paul and law
Two realms level roles - Admin and Reader
Two client level roles - demo-admin and demo-reader
Please note that I will using Keycloak 12.0.4 and I will skip almost all the basic setup instructions. I will only share the relevant bits. If you're not sure how to set this all up, please check out the Getting Started Guide or this answer. The answer contains steps for version 8 but the differences are very minor as far as I could tell.
Associating Users And Roles
In order to associate paul with the Admin, Reader, bank-admin and bank-reader roles, please do the following:
Click on Users > View all users > Click on the ID value for paul > Click on Role Mappings > Under Realm Roles move Admin and Reader under Assigned Roles > Select my-demo-client under the Client Roles select box and move demo-admin and demo-reader under Assigned Roles like so
As for law we'll just associate him with Reader and bank-reader.
Associating a client scope with a client
Create a Client Scope by:
Clicking on the Client Scopes link on the left > Click on Create > Enter custom-client-scope for the Name field and Hit Save. It should look like this
Click on Clients on the left > Select the my-demo-client > Click on the Client Scopes tab at the top > and let's just move it to Assigned Default Client Scopes for convenience.
Inspecting the Access Token
We can easily generate an access token for our setup via Keycloak to see what it looks like. In order to do so:
Click on Evaluate tab under Client Scopes.
Select paul as the user
Click on the blue Evaluate button
Click on Generated Access Token. While inspecting the token, look for:
resource_access to see client level roles associated with paul
realm_access to see paul's realm level roles
scope to see the Client Scope that we created called custom-client-scope
If you generate a token for law, you would see less roles when compared to paul.
Obtaining a Scope After Policy Evaluation
Continuing with our setup:
I've created an account/{id} resource with two Authorization Scopes called account:read and account:modify like so
Additionally, I've created two role based policies called Only Reader Role Policy and Only Admin Role Policy where the former requires the Reader realm role while the latter requires the Admin realm role. Here's an example for reference.
Note that you can further enhance that policy at the client level if you wish but to keep things simple, I chose not to do so.
Furthermore, I've created two scoped based permissions called Read Account Scope Permission and Modify Account Scope Permission.
The Read Account Scope Permission will grant the account:read Authorization Scope if the user is either an Admin or a Reader. One key thing to notice here is the the Decision Strategy has to be set to Affirmative in order to achieve this behavior.
Modify Account Permission on the other hand grants the account:modify Authorization Scope to users with the Admin role.
Now, if you choose the evaluate the user paul (remember he is both Admin and Reader) against the Account Resource, he will be granted both the account:read and account:modify Authorization Scopes. Let's see if this true. Here's our Evaluate screen and notice that I did not associate any roles with paul since this was already done via the Users > Role Mappings tab
And here are the results of that evaluation as predicted
Here is the evaluation result for law. Since he's not an Admin he'll be denied the account:modify scope but he'll be granted the account:read scope.
And finally, we can further confirm this by click on Show Authorization Data which shows the permissions inside the access token for law
Hopefully this helps you see where each piece of the puzzle fits in your architecture. Cheers!
I have a lot of APIs that are to be dual-use, by both an end-user and administrative staff. I will use preferences and give two examples:
/user/preferences - This give the end-user their preferences
/users/{user}/preferences - This gives any person's preferences
Clearly this is leading to duplication. Of-course, I can use only '/users/{user}/preferences' for both end-users and administrators, but then I end up with other problems:
1) The person will need to put in their user ID into each call, which is clunky.
2) Security will now become a problem, as the backend needs to ensure that each request is being managed correctly, i.e. A malicious person cannot put in another person's ID and retrieve their preferences.
What's the best pattern to follow here?
One option is to make the /user/preferences take an optional ?userid= parameter for the admin calls. Then you can use the same endpoint and branch based on admin == true && args[userid].
The comment on proxy api endpoints is good too where a less specific call (/user/preferences) calls a more specific endpoint (/user/{userid}/preferences).
Either are good options. A lot of people put all the admin calls under /admin/... and add a handler to verify the caller is actually an admin before routing to the regular calls (/admin/users/preferences -> verify is_admin -> /users/preferences?userid=bob).
Before first sending signing request I should get a accountId.
So is there any expiration time for this accountID? Can I save it and use it any time with unlimited time if there is no changes in credential or/and other api key and so on?
I can't find information about strategy for accountId in rest api documentation.
Thank you
ref:
https://www.docusign.com/developer-center/recipes/request-a-signature-via-email
https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Login.htm
The account ID is part of your developer account. You can find it when you login by clicking on the little down arrow in the top right corner next to your avatar. It will display your name the name of the company then a number. That is the account ID.
The account ID does not expire. The way DocuSign manages access to the API's is through an Integrator key. For information about the Integrator key please refer to the following link. https://www.docusign.com/developer-center/api-overview
So from a broad overview you would want to break up the different business processes by business group and have a different Integrator Key for each unit. That way if someone builds bad code or something strange happens and they turn of one of the Integrator keys it does not affect every group in the company.
There is no expiration of your accountId however note that it will change between environments - i.e. when you move from demo to production. Therefore the best practice is to write your integration such that, for a given user, it makes the login call then uses the accountId returned from that in subsequent API requests. By writing it this way you also make the go live process easier since you wouldn't have to remember to go back and change any hard-coded values in your app.
Note that when you are in production, your organization (or your customers' organizations) may well have more than one account id. And that individuals within the organization may well have access to more than one account.
Example: a company has different rules for electronic signature requests that are sent from the legal department and all the other corporate departments. Depending on the differences in the rules, the best DocuSign configuration may be to establish two different accounts, one for legal and one for everybody else. And some people may have access to both accounts.
Bottom line: when your API integration app logs in, it should enable either the human or your config file to specify the account that should be used (if the user has access to more than one account.) While all users have a "default account," it is not always the case that the default is the one that should be used by your integration.
I'm making a application for facebook that will be used for academic research. Right now when the user goes to install the application I'll request additional information which is stated in the extended permissions.
I would perfectly understand someone not wanting to give out certain aspects of this information (It's just used to gather statistics about people taking part , education, religion etc.)
Does anyone know the best way to filter the permissions? For instance maybe someone is willing to give their age but not education. Therefore can I remove the education request from my application install request dynamically?
If you want to ask the user for only those permissions that he wants to give, you can take input from him before redirecting to Facebook login. You can generate the url for requesting permissions based on this custom set of permissions using the 'perms' attribute of the <fb:loginbutton /> tag or pass the list of permissions you want to the $facebook->getLoginUrl(array('req_perms' => $perms)) call.
To keep track of permission changes, you can use the realtime updates offered. You can know more about it here.
You certainly could build an up-front permissions matrix that the user could cherry-pick from. And that would probably be the way to do it, since you can't do anything to customize the permission challenge that the Facebook Platform generates.
The trick would be keeping track of which permissions the user granted in the given access token you'll receive from back from the Platform. Especially since users can change the permissions granted to your application w/o visiting the application itself - so you'll want to be hooked in to that info via the Real Time Updates.