Web Api: Simultaneous Calls for One User Id
However, when multiple clients simultaneously call the custom web service the creation of each subsequent session token appears to invalidate the previous session token. For example, client A submits a batch of records, then client B, and finally client C. A session token is created for client A using the user id created to be used by the custom web service. When the custom web service receives the batch from client B, it creates a session token using the user id created to be used by the custom web service. However, when that session token is created for client B, the session token for client A becomes invalid.
How can multiple, simultaneous calls be made to the Archer web apis using the same user id? We don't want to create custom user ids that would be called by each individual client. Instead we need to multiple calls to the Archer web apis to work in parallel.
Due to the nature of user session tokens within the platform, you would need either a separate user accounts for each client or to pass the token from client to client (which is likely not possible nor advisable). Anytime that a user authenticates, whether through the API or otherwise, the prior session token is canceled and a new one is issued. There is not a way to change or modify this functionality.
Jason, this is a little surprising. There are many valid use cases for why this is needed.
For example, we plan to automate creation of Incidents in Archer Incident Management from within the ArcSight SIM console. We have 20 cyber security analysts working in ArcSight at any given time, and we are developing an integration between ArcSight and the Archer API to automate creation of Archer Incidents when an analyst clicks on an ArcSight event in the Arcsight Console that calls the Archer APIs. Those API calls need to go through a single Archer user account specifically created for calls from ArcSight with the limited and appropriate privileges needed to create those incidents. We cannot be creating and maintaining 20 additional Archer acccounts for every possible Archer user for this one integration point. This use case also exists for a number of other external applications that we need to integrate with Archer. What would you see as a more appropriate way to do this than with a single account specifically created for and configured with the correct rights/permissions? It seems to me that the Archer API should have a method that allows to query for the integration account username and return the existing token that can then be utilized by all the calls to the Archer API for that integration. What other option would you suggest for this use case?
Also, keep in mind, that multiple analysts could be invoking that integration simultaneously or within minutes of each other, so we cannot create/terminate the session each time as that would kill any calls that are in progress. Hence, the need to reuse the existing token of the single, configured account.
Based on your description, I can definitely see the advantages of having this capability. However, the only recommendation that I can make would be to log an idea to get this added to a future release.
An option that could be possible would be to programmatically query the database to determine if a session token exists and use it, otherwise create one. You'll want to be careful not to open any security holes if you decide to do something similar.
What is the best practice for user task delegation via API calls to Archer? If end users have different levels of access but there's only a single web API user account performing the tasks, how do you not clobber the access rights to records and fill the audit logs with a single user account?
Is there a way to provide the end user account info in the web API calls to perform the tasks as the end user? Or is there a way to use the user's session token? We're in SaaS so we don't have access to query the database.
It seems like you need the custom web service to simply keep a single session alive, simply 'pinging' the platform using some method to keep the session alive and passing the token to the child processes as requests are being made. I am planning the same thing for numerous services we have. This solution is especially meets Chris's needs above as well. Your integration would manage its workload thru a single session token.
Service logs in either once indefinitely or does regular log-in/out daily if desired. Simply call some simple function (Like GetRecordByID) to keep the session alive as needed. Then simply passes that Session token around as necessary.
It seems to me that the Archer API should have a method that allows to query for the integration account username and return the existing token that can then be utilized by all the calls to the Archer API for that integration. What other option would you suggest for this use case?
This would be a huge security risk. Providing an API which queries for a session token would be paramount to giving a hacker the tools to hijack sessions.
Gene is right about that. In order for that to work you would have to have a valid session to request the session token of another account. Two problems here, you defeat the requirement to not require multiple accounts and you provide a way for account sessions to get hijacked.
You are far better off building your own service to manage the login for your other processes.