We have an internal API which consumes data from our Thinkwise application through Indicium.
Up until recently we had been using Indicium Basic, however recently we have started our upgrade to Universal.
For authenticating users with Indicium through the API, in Basic we used the URL indicium/(sf|iam)/<app_id>/$logout, to which we would send a basic authentication header supplied by the client calling the API. However, in Universal this endpoint does not seem to exist anymore.
Is there a similar endpoint in Universal which allows us to authenticate users through a basic auth header? Other ways of authenticating users are of course also welcome, but some form of username/password authentication is preferred.
Thanks in advance!
Page 1 / 1
In the universal version the login seems not directly to be related to the apps. You'll first need to login and then get the available apps per environment. Next you can get the data.
There is an api for logging in: /indicium/account/api/login
With this link you can authorize yourself against your indicium instance. If you want the app then you'll need to call more API's
There is an OpenAPI implementation available for all applications so you can see which endpoints there are.
This post might help you:
In the universal version the login seems not directly to be related to the apps. You'll first need to login and then get the available apps per environment. Next you can get the data.
There is an api for logging in: /indicium/account/api/login
With this link you can authorize yourself against your indicium instance. If you want the app then you'll need to call more API's
There is an OpenAPI implementation available for all applications so you can see which endpoints there are.
The Open API spec will definitely help, cheers!
I tried calling the URL you specified, but it returns a 404 response. Our IIS site for Universal is named indicium_universal, so I assume in my case I would need to POST to http://<server>/indicium_universal/account/api/login with either a basic auth header or a user/pass combination in the request body?
Hello Jeroen,
If you want to log in to Indicium Universal by means of an API call with a username and password, then there are two options:
The preferred method uses cookie authentication. This means that you send a login request to an endpoint and in return you will receive a cookie that serves as an authentication ticket for some time. For this to work, it is necessary that the client has some way of keeping track of the cookies and sending it along with subsequent requests (like browsers do). You can send a form-data POST request to /indicium/account/api/login with the parameters UserName, Password and optionally RememberLogin. Logging out can then be done by sending a POST request without a body to /indicium/account/api/logout. The only thing that this request does is clearing the cookie.
You can still use Basic authentication as well, but ultimately this will also return a cookie that serves as an authentication ticket. The idea is that you only add the Basic Authorization header once (to any request) and then send the cookie with subsequent request. However, it is possible to just ignore the cookie and attach the Basic Authorization header every request. This also means that there is no point in logging out, because the cookie is not used anyway.
Aside from this, it’s also possible to work with OAuth access tokens and refresh tokens, but then we’re leaving the realm of simple username/password authentication.
I hope this helps.
Hello Jeroen,
If you want to log in to Indicium Universal by means of an API call with a username and password, then there are two options:
The preferred method uses cookie authentication. This means that you send a login request to an endpoint and in return you will receive a cookie that serves as an authentication ticket for some time. For this to work, it is necessary that the client has some way of keeping track of the cookies and sending it along with subsequent requests (like browsers do). You can send a form-data POST request to /indicium/account/api/login with the parameters UserName, Password and optionally RememberLogin. Logging out can then be done by sending a POST request without a body to /indicium/account/api/logout. The only thing that this request does is clearing the cookie.
You can still use Basic authentication as well, but ultimately this will also return a cookie that serves as an authentication ticket. The idea is that you only add the Basic Authorization header once (to any request) and then send the cookie with subsequent request. However, it is possible to just ignore the cookie and attach the Basic Authorization header every request. This also means that there is no point in logging out, because the cookie is not used anyway.
Aside from this, it’s also possible to work with OAuth access tokens and refresh tokens, but then we’re leaving the realm of simple username/password authentication.
I hope this helps.
Hello Vincent,
Thank you for the thorough answer. I think I got the first option working in Postman, however it keeps telling me I am already logged in to my account, even after POST-ing to /indicium/api/logout as well as /indicium/ui/logout after logging in to the web GUI. Also, after successful login, which of the request cookies is the authorization ticket? The only request cookies I am seeing in the web GUI in requests after login are ".AspNetCore.Antiforgery.<some_token>", ".AspNetCore.Identity.Application" and ".AspNetCore.Session”.
Say I go for option 2 and ignore the cookie, are there any major performance costs? Will the user be re-logged with every request if I supply the auth header, or will it detect the user is already authorized and carry on with the request? That would mean less change in our API to accommodate the new way of authorizing users, but if this is not or should not be desired for a proper implementation of Universal, we will obviously rework it to accommodate option 1.
Hello Jeroen,
I think I got the first option working in Postman, however it keeps telling me I am already logged in to my account
Are you supplying Basic authentication through Postman as well? You should do one or the other, not both. So you either use Basic authentication or you POST to /account/api/login.
Say I go for option 2 and ignore the cookie, are there any major performance costs? Will the user be re-logged with every request if I supply the auth header, or will it detect the user is already authorized and carry on with the request?
There will be some performance cost, but it is hard to say how much this will affect your use case. The user will indeed be logged in with every request if you don't supply the cookie, because the cookie is exactly the mechanism through which Indicium would determine that the user is already logged in. There is no server-side state in Indicium regarding users being logged in or not. This is also why user's authentication sessions can survive Indicium restarts. The authentication cookies are entirely self-contained.
I don't think that the performance cost on any single request will be very severe. If I would have to make an estimate, then I would expect something along the lines of 50-200 milliseconds. However, it is important to weigh how many API calls will be performed per user in a certain time frame. Despite the performance hit being relatively small, you will incur it on every single request. Furthermore, every request will log an entry in IAM's Session log table, which could cause it to grow very quickly. If we're talking about a few hundred requests spread over a day, then I don't think it's that big of an issue. However, if it will be more like a few dozen requests every minute, then I would definitely recommend the cookie approach.
IAM's Session log
I hope this helps.
Are you supplying Basic authentication through Postman as well? You should do one or the other, not both.
I am trying to log in using the basic auth header only, yes. I tried using the request body instead, but it kept saying the UserName-field was required even though I had supplied it and named it correctly in the JSON.
Could it be that Indicium is having trouble authenticating my account because it is a domain account? The account I use in Indicium is the same I use to log into Windows, remote desktops and everything else I have access to in my organisation. Could Indicium be detecting that I am logged in to my domain account in Windows, for example, and therefore think I am already logged in?
If we're talking about a few hundred requests spread over a day, then I don't think it's that big of an issue. However, if it will be more like a few dozen requests every minute, then I would definitely recommend the cookie approach.
Cookie approach it is. The clients using the API are making well over a dozen requests per minute, and we do not want to overload the database and/or Indicium instance.
Hello Jeroen,
I am trying to log in using the basic auth header only, yes. I tried using the request body instead, but it kept saying the UserName-field was required even though I had supplied it and named it correctly in the JSON.
There is no need to call any kind of login endpoint if you are using Basic authentication. These are two separate methods for logging in and you are using both simultaneously. This is why you're getting the message that you are already logged in.
Since you want to save cookies for performance reasons you can choose either of the following flows.
Option 1
Call /account/api/login without a Basic Authorization header (instead, you supply the username and password in the form-data POST body.
Save the cookie from the Set-Cookie response header
API call 1 (include the saved cookie in a Cookie request header)
API call 2 (include the saved cookie in a Cookie request header)
…
Option 2
API call 1 (add a Basic Authorization header to this request)
Save the cookie from the Set-Cookie response header
API call 2 (don't add a Basic Authorization header to this request, instead include the saved cookie in a Cookie request header)
API call 3 (don't add a Basic Authorization header to this request, instead include the saved cookie in a Cookie request header)
...
In both of these scenarios you could choose to call POST /account/api/logout at the end of a user session, but the only thing this does is return a Set-Cookie response header with an empty cookie to override the user's authentication cookie. As said before, there is no server-side state that makes logging out necessary, however it will cause the Ends on column in IAMs Session log to be filled out, if you're interested in that.
I hope this clarifies things.
Call /account/api/login without a Basic Authorization header (instead, you supply the username and password in the form-data POST body.
Save the cookie from the Set-Cookie response header
That was it! I was supplying the user/pass combination as a JSON body, not as form data. Changing it to that fixed it. Going to work this into the API now and see about providing the cookie to the Indicium request.
How long would these cookies be valid for? Or is that a per-instance configuration? If the expiry time is limited, we will need to introduce a refresh method into our API.
In both of these scenarios you could choose to call POST /account/api/logout at the end of a user session, but the only thing this does is return a Set-Cookie response header with an empty cookie to override the user's authentication cookie. As said before, there is no server-side state that makes logging out necessary, however it will cause the Ends on column in IAMs Session log to be filled out, if you're interested in that.
I will look into whether this is necessary for our use cases. It might be cleaner, but I've been told sessions are automatically ended when inactive for a certain period of time.
Cheers for the help and clarifications!
Hello Jeroen,
How long would these cookies be valid for? Or is that a per-instance configuration? If the expiry time is limited, we will need to introduce a refresh method into our API.
Authentication cookies are valid for 30 minutes by default, but they are automatically extended while being used. So it will be valid until it is not used for 30 minutes. Furthermore, specifying RememberLogin as true in the login request will cause the cookie you receive to be valid for 14 days (again, extended automatically).
