Hello,
We will expose several OOB RSA Webservices to 3rd path applications. As you know each ws requires a token to be retrieved by "loginUser" web service in the first place.
We do not want to give default admin credentials to the requestor. What should the correct approach be? Can we create a new "technical" user and give him web service request privileges? If so, what is the correct privilege to assign?
Have a look at the: User : Delegate Web Service Requestor All Aveksa Entitlement . This is also listed in the Admin guide if I'm not mistaken.
Hi Tim ,
Thanks! It works for existing (collected) users. But collected users are actual people. What need here is basically a user, a technical one, like a user in oracle, that will be provided to 3rd party application for only token retrieval purpose. Is not it possible?
I was wondering the same thing a few weeks ago and created a simple 'solution'. A new identity collector that collects specific technical users into our environment from a local aveksa database. I know it's not the best solution and have not implemented it at production, but it works perfectly at our development environment.
Thanks Tim,
I hope the products provides an OOB solution for this. Let's hear if anyone else has a say in this.
The loginUser web service is expecting the username and password for a collected user or the AveksaAdmin account. I have seen some solution where a service account is defined with no privileges to serve this purpose as well.
The OnBehalf of feature mentioned earlier in this thread can then be used to make change requests on behalf of other users. Other operations however like collectIdentities are going to rely on the logged in user's privileges to determine if the web service operation is allowed. The token plays a key role in ensuring you cant just do anything in the world once logged in.
Hello all,
We are preparing our production env. and we need to find the correct way to expose webservices for other systems. As Tim Willemstein mentioned earlier, we can create a new user using a dummy identity collector which simply collects users from a local csv file (or database) where we define this new user for webservices.
But is this the best practise to follow on production env?
In any case, suppose that we follow this approach how should set the password for the local ws user created?
The loginUser web service is expecting the username and password for a collected user or the AveksaAdmin account. I have seen some solution where a service account is defined with no privileges to serve this purpose as well.
The OnBehalf of feature mentioned earlier in this thread can then be used to make change requests on behalf of other users. Other operations however like collectIdentities are going to rely on the logged in user's privileges to determine if the web service operation is allowed. The token plays a key role in ensuring you cant just do anything in the world once logged in.