If I want my app to be distributed to multiple workspaces, how will I then manage my tokens? I cannot hard-code the same token as it is unique for each workspace.
You'll make use of the 'redirect url' to capture generated token and store it in a cache or db depending on your implementation.
Following documentation may help:
https://slack.dev/java-slack-sdk/guides/app-distribution
https://api.slack.com/authentication/oauth-v2
Related
My application is composed of an API layer which is accessable by presenting a Bearer Token, obtained from our Identity Server. Each of our API has a level of scopes that the token must contain in order to be invoked: this means, for example, that if you want to make the API call which "creates a product" you need a write access to products (i.e. the scope "products") while you may just need the scope "products_read" if you only want to retrieve them.
Scopes are bound into the token when you authenticate onto the ID server.
Now, I need this user to be able to perform different operations on different "workspaces". Each workspace administrator can set which permissions each user have. This is, in fact, linked to the scopes that each user will have when operating on that particular workspace.
Right now we have implemented that, if you are trying to access a different workspace, the API layer will check:
if your bearer token is valid (by validating it on the ID server)
if you are authorized to access that workspace
changing associated claims by removing the original "scopes" (set into the token by the ID server) and overwriting with those assigned by the administrator of that workspace
This somehow works, but it stinks because I don't want my application layer (API) to have this kind of responsability and the opportunity to tamper with the token. I want the ID server to handle it and, after the user tries to enter into a different workspace, it generates a new crafted bearer token with correct claims (so the API will just need to trust it).
What's the best approach in doing that? I'm digging into the "custom grant type": may this be the right approach?
Scopes are fixed at design time and the same for all users. I like your use of products and products_read - that is very standard.
When you need dynamic behaviour, implement claims, which depend on who the user is. In your case I would use a workspaces array claim. Since this is a key vaue for authorization, it should be added to access tokens at the time of token issuance. Think in terms of your products scope being composed of claims.
It feels like workspaces and other permissions are part of your business data rather than your identity data. At the time of token issuance, IdentityServer should send identity attributes (eg subject claim) to an API endpoint you provide. which returns business attributes (workspaces). I believe in IdentityServer this is done via a custom profile service.
I'd try to avoid different tokens for different workspaces, since that will be awkward in terms of usability and code complexity. The standard way to do it would be to redirect the user each time.
I have been trying to setup Jenkins api token so that I can use it tin python codes.
Is there any expiry for the Jenkins api token created via the UI.
There is no time limit set for the expiry of the Jenkins API token. However, the best practice is to keep on changing after a long period change to avoid security risk.
You can find more about Jenkins API token here in this blog
Just wanted to put this out there for anyone having a problem with their token disappearing. The API token does not expire, but it can get wiped out on some Jenkins controllers.
We use CloudBees SDA, and I discovered after many iterations of creating and losing my token that the token has to be generated at the Operations Center level rather than the Client Controller level, because the latter gets synched to the former periodically (at least the way we have it configured).
See here for more information.
Is there a way to set the API token of a user manually? In the UI it has a button "Change API Token" which generates the token. Instead I want to set it.
Our old jenkins server crashed and we have to create a new one. Lot of teams are using a remote trigger call similar to below one. Change in the API token impacts all these teams as they have to update their code.
curl -X POST -H "$CRUMB" "http://automation:ef*****************************d#jenkins-url.com/job/log_deployment/buildWithParameters?token=B6472A215********************
The API token in UI is 32 char long. Upon checking the file in jenkins/users//config.xml there is this property jenkins.security.ApiTokenProperty. Seems like it is possible to set this, need some direction please.
<jenkins.security.ApiTokenProperty>
<apiToken>{AQAAABAAAAAwOROgeIy1vAUUOtGIYud+70TXY0pS/pKTe7nLeO8Xtd2BDgXW1RlZ6pL9+bvDrbwHh2xBnebPJAUS3OQt8f/toQ==}</apiToken>
</jenkins.security.ApiTokenProperty>
Thanks!
Update: More info from
https://issues.jenkins-ci.org/browse/JENKINS-32776
User
passwords are stored as salted hashes (SHA-256 or bcrypt); whereas API tokens
are encrypted using an AES-128 ECB-mode block cipher, using a static key shared
among all users.
You cannot set a given token explicitly since Jenkins only stores the hash of a token.
You can, however, copy the hashed value, thus effectively copying a token.
To do this between different masters with different global encryption keys, you need to decrypt the hash of the first master and use that for setting the hash on the second master. It's probably easiest to do that in groovy.
I have two questions about Box's Oauth2 API in a testing environment.
Is it possible to have multiple redirect_URI addresses? I'd like to use one address for production (e.g., https://my_site.com/box_redirects_here), one for ongoing development (http://localhost:8000/box_redirects_here) and one for automatic UI tests (http://localhost:8001/box_redirects_here). As far as I could see, the only way to do that would be to create three different Box applications - is there an easier way? BTW, both Dropbox and Google Drive do support multiple redirect URIs.
I have a set of automatic tests that I'd like to run a few times a day. The challenge I'm facing is that every time I run these tests, my refresh_token is invalidated, and I can't use it again - which means I can't run the same set of tests a few hours later without manually getting a new token. One solution would be to save the refresh token, for example in a file, so I could reuse it across testing sessions. But:
It's really cumbersome.
if different developers are running these tests from different machines with no common file system that doesn't really work.
Again, for whatever reason this doesn't seem to be an issue with Google Drive or with Dropbox.
This is not currently possible, and I agree that would be nice.
Your best option is to save the access/refresh token pair to a file or a database (in the event that there's no common filesystem.) The OAuth2 spec grants implementers wide latitude on how they issue refresh tokens, if they issue them at all (I don't think Dropbox does.) While Box's implementation makes integration testing a bit challenging, I think that it ultimately hews most closely to the spec's recommendations.
For your first question, you might be able to get close to what you want by using the redirect_uri query parameter. Although you won't be able to supply an arbitrary redirect URI, you can give one that has the same base URL as the redirect URI in your app console.
From the OAuth tutorial:
Wildcard redirect_uri values are also accepted in the request as long as the base url matches the URI registered in the application console. A registered redirect_uri of https://www.myboxapp.com can be dynamically redirected to https://www.myboxapp.com/user1234 if passed into the request redirect_uri parameter.
For your second question, John is right - Box invalidates a refresh token after it has been used. Although this can be annoying, it's also more secure.
I am trying to implement XPagesSBT on localhost.
I have followed this article http://heidloff.net/home.nsf/dx/12152011034545AMNHECAP.htm and the SBT document by Niklas and was trying to implement dropbox oAuth.
I have also placed http://localhost/XPagesSBT.nsf/ and http://localhost/WebSecurityStore.nsf in root folder
but still i get this error
Error while executing JavaScript action expression
Script interpreter error, line=1, col=26: Error calling method 'isAuthenticated()' on java class 'com.ibm.xsp.extlib.sbt.services.client.endpoints.DropboxEndpoint'
No application is registered with id XPagesSBT and provider Dropbox
if(!#Endpoint("dropbox").isAuthenticated()) {#Endpoint("dropbox").authenticate(true);}
do i need to make any other configuration /setup to XPagesSBT db? or it wont work with Localhost?
I don't remember exactly anymore but reading my blog entry you linked it says you shouldn't use Anonymous:
"Additionally there are a couple of security related settings which are important to understand. First of all you need to assign access to the document with the application keys to the ID with which you signed the two NSFs. In the screenshot above I've entered both OpenNTF servers and my own user ID. When you use the web UI to do this these names are added to the document in an authors field and a readers field.
In the last step you need to configure the ACL of the security store. Anonymous must not have access to this database. All users who you want to be able to use the Social Enabler OAuth functionality need to have author access. This is so that their user keys can be stored in this database so that they only have to do the OAuth dance once. "
It should work on localhost. It looks like a configuration issue with SBT not being able to read the security tokens from the websecuritystore.nsf . Did you create the Dropbox Application Key with an admin id and sign the websecuritystore with the correct id?
Padraic