I am writing a some PowerShell scripts to log into Azure AD using a clientid/secret.
The code for obtaining a new access / refresh token is very simple. I have a Get-Token function with all the error checking etc in about 80 lines of code.
If I write Get-Token so that it will decide whether to get a new token, send an existing one or to obtain a new one with a refresh token would invariably be considerably more complex.
Is there any benefit to renewing tokens rather than simply obtaining a new one each time the function is called? (considering there is no consumer side to this, it is a backend script to connect to Azure services)
ETA
This isn't using ADAL, it is using raw HTTP requests, so I'm managing the tokens directly.
Related
I'm using Matlab's webread function to read lists from my organization's Sharepoint. I went through a detailed process to generate a token in Postman (with client_id, client_secret, etc). I then send this token via the webread function and this works perfectly in reading the SP lists. So far, so good.
However, the Sharepoint access token expires every few hours. I manually create a new one in Postman each time and manually paste it in my Matlab script. I've read about creating longer-lasting 'refresh' tokens that are generated automatically. Being mainly a Matlab user and not an I/T person, I cannot for the life of me figure out how to create these refresh tokens.
A second (less desirable) alternative would be to use catch/try to check if the current token has expired and create a new one. That command is also quite complicated needing realm, client-id, client-secret, etc. Here also, I cannot figure out how to structure the webread argument to send all this information.
Has anyone has successfully kept a continuous REST API connection from Matlab to Sharepoint without expiring tokens? Are there any other (better?) alternatives to using tokens? I'd greatly appreciate a gentle, step-by-step procedure on how to do this.
TIA
Succesfully generate the initial token, seeking help on a non-expiring REST API connection between Matlab and Sharepoint.
I’m currently working on a PoC with multiple Quarkus services and Keycloak RBAC. Works like a charm, easily to bootstrap and start implementing features.
But I encountered an issue that I could not solve in my mind. Imagine:
User accesses a protected service
quarkus-oidc extension does fancy token obtaining by HTTP redirecting, JWT in cookie lasts 30 minutes
User is authenticated and gets returned to the web application
User works in application, fills in forms and data
Data is being stored by JWT-enriched REST calls (we do validation by hibernate-validator)
User works again, taking longer than 30 min
Wants to store another entry, but token from step 3 is now expired and API call fails
User won’t be happy, so me neither
Possible ways to solve:
Make the JWT last longer than the current 30 minutes, but that just postpones the issue and opens some security doors
Storing users’ input in local storage to restore it later after a token refresh (we also would do that to not loose users’ work)
Refresh the token „silently“ in JS without user knowing. Is there a best practice for that?
I missed something important and the internet now tells me a better architecture for my application.
Thank you internet!
Re the step 3. In Quarkus 1.5.0 adding quarkus.oidc.token.refresh-expired=true will get the ID token refreshed and the user session extended if the refresh grant has succeeded
For such use cases, I tend to prefer the reverse of JWT. I keep the user data in a shared data service (a data grid like Infinispan or Redis). So that this data is keyed by the user and available. I do control the TTL of that data in the shared data service.
It can either be specific to an app, or shared between a small number of apps. It does bring some coupling but so does the JWT property structure.
For Quarkus, there is an Infinispan client integration, a Hazelcast one, mongodb and AWS dynamoDB. And you can bring other libraries.
I am a bit confused. The requirement is that we need to create a REST API in Salesforce(Apex class) that has one POST method. Right now, I have been testing it with POSTMAN tool in 2 steps:
Making a POST request first with username, password, client_id, client_secret(that are coming from connected app in Salesforce), grant_type to receive access token.
Then I make another POST request in POSTMAN to create a lead in Salesforce, using the access token I received before and the body.
However, the REST API that I have in Salesforce would be called from various different web forms. So once someone fills out the webform, on the backend it would call this REST API in Salesforce and submits lead request.
I am wondering how would that happen since we can't use POSTMAN for that.
Thanks
These "various different web forms" would have to send requests to Salesforce just like Postman does. You'd need two POST calls (one for login, one to call the service you've created). It'll be bit out of your control, you provided the SF code and proven it works, now it's for these website developers to pick it up.
What's exactly your question? There are tons of libraries to connect to SF from Java, Python, .NET, PHP... Or they could hand-craft these HTTP messages, just Google for "PHP HTTP POST" or something...
https://developer.salesforce.com/index.php?title=Getting_Started_with_the_Force.com_Toolkit_for_PHP&oldid=51397
https://github.com/developerforce/Force.com-Toolkit-for-NET
https://pypi.org/project/simple-salesforce/ / https://pypi.org/project/salesforce-python/
Depending how much time they'll have they can:
cache the session id (so they don't call login every time), try to reuse it, call login again only if session id is blank / got "session expired or invalid" error back
try to batch it somehow (do they need to save these Leads to SF asap or in say hourly intervals is OK? How did YOU write the service, accepts 1 lead or list of records?
be smart about storing the credentials to SF (some secure way, not hardcoded). Ideally in a way that it's easy to use the integration against sandbox or production changing just 1 config file or environment variables or something like that
I'm new to Shiro. We are attempting to use Shiro with Stormpath. I've been trying to dissect the examples to come up with a solution to what I want to do, but I'm unsuccessful so far.
For now, I'm simply trying to create REST services to do what I want, and I'll tie a real client in later. This is what I'm trying to achieve as my first step:
I want to have a client hit a REST endpoint (login) on my server. My server would authenticate, and return a JWT to the client. This JWT would then be used to access secured endpoints on my server. (I have written Java code that can successfully authenticate against Stormpath).
My problem is the JWT. I expected that a JWT would be created for me, or at least easily accessible. I can't find a way to get one. I have seen sample code on how to build one, but that doesn't seem like the way I would expect to acquire one.
I have run through several examples, but most seem to deal with JSP interfaces, and I can't seem to make the leap to what I'm trying to do.
Is this approach reasonable? Any guidance is appreciated.
Edit 1
I now have a Java client that can authenticate using the Shiro servlet and retrieve a JWT. I have this running as a deployed application (war) in GlassFish. My next step is to use that JWT to authenticate against a different application that has my REST endpoints. This REST application doesn't need to know anything about how to authenticate - I just want to pass the JWT along in the call to a given REST endpoint and use Shiro (via annotations) to control access to the endpoint (if that is indeed possible). All of the examples I can find seem to be "all-in-one" examples (bundling JSP with Shiro/Stormpath configurations, etc). I'm trying to determine the minimum working configuration for securing REST endpoints and I'm having difficulty determining which pieces of the configuration I need.
Edit 2
I am using the Stormpath-Shiro-Servlet (as stolen from the Shiro Servlet example) as my authentication back-end. Using my Java client, I am sending a login request to the servlet, and I am indeed getting back a JWT. However, I am not able to successfully use the JWT to access my other rest resources. My rest calls result in this error:
org.apache.shiro.authz.UnauthenticatedException: This subject is anonymous - it does not have any identifying principals and authorization operations require an identity to check against. A Subject instance will acquire these identifying principals automatically after a successful login is performed be executing org.apache.shiro.subject.Subject.login(AuthenticationToken) or when 'Remember Me' functionality is enabled by the SecurityManager. This exception can also occur when a previously logged-in Subject has logged out which makes it anonymous again. Because an identity is currently not known due to any of these conditions, authorization is denied.
First, I don't understand why the servlet 'login' doesn't actually log me in and give me non-anonymous principle? Second, I am attempting to do everything on a separate client, so I don't have access to Subject.login (is this a correct assumption?).
Take a look at this example from github/stormpath-shiro
The JWT creation is managed for you by the Stormpath API. If you start up one of the examples, (the servlet one above, or the spring-boot-web example), after login, you will have a JWT cookie. There is background info in this blog post.
I'm working on releasing strompath-shiro now, but figured I'd include these link here so you can start looking.
I am working on a webapi project which of course is supposed to be stateless.
The point is that it requires authetication and the majority of it's services is available to logged in users.
The catch is that there are several pieces of information about that user which should be used on all subqsequent calls to the legacy backend.
Should I force the clients to send back all those parameters on each request? (doesn't seem fair)
Should I use a caching on the webapi side - this is tricky as currently there is no out-of-memory distributed cache in use in the deployment environment....
What options do you see?
You could choose to issue the user some kind of session token on the first call. The server could then use the session token to authenticate the user and remember the settings for that session on subsequent calls.
You can read more about managing sessions in a stateless environment here:
http://en.wikipedia.org/wiki/Session_management