We decided to create a separate program that will handle getting the API keys. At least until we have single sign-on enabled on both MAS and the requesting app,
Thanks for all the responses as they really helped in making the decisions.
Original Message:
Sent: Mon January 13, 2025 02:24 AM
From: Andrzej Więcław
Subject: Alternatives for using maxauth in API Calls in MAS9
Hi Willem,
as Aneesh said you would need to somehow make sure that user gets authenticated first so that you're sure he is who he claims to be (could be common identity provider with Maximo or any other that you trust) and then you could do the same trick with obtaining the dedicated user APIKEY
but using pre-generated APIKEY
and then keep on using newly acquired one in future interactions.
This is an example MXAPIAPIKEY
object structure inbound processing automation script which allows overriding default MX logic which always try to generate new APIKEY
for given user, with one returning existing key if such exists. This way you can always call "create API key" endpoint and either new key will be generated or existing one will be returned.
from psdi.server import MXServer;from psdi.mbo import SqlFormat;def mboRules(ctx): data = ctx.getData(); sqlFormat = SqlFormat(ctx.getUserInfo(), "userid = :1"); sqlFormat.setObject(1, "MAXUSER", "USERID", data.getCurrentData("userid")); mboSet = ctx.getMboSet(); mboSet.setWhere(sqlFormat.format()); ctx.setMbo(mboSet.moveFirst());
You can then call MXAPIAPIKEY
endpoint as follows:
curl --location --globoff '{{MAXIMO_URL}}/os/MXAPIAPIKEY' \--header 'x-method-override: SYNC' \--header 'properties: *' \--header 'Content-Type: application/json' \--header 'APIKEY: ••••••' \--data '{ "expiration":"-1", "userid":"{{USERID}}"}'
It's important to use x-method-override: SYNC
header to achieve proper endpoint behavior.
Of course you should assess how secure is it to generate APIKEY
with no expiration. Perhaps a bit better idea is to request these for a certain fixed time and then extend inbound processing script to update APIKEYTOKEN.CREATIONDATE
every time you identify this as appropriate to extend the validity.
------------------------------
Andrzej Więcław
Maximo Technical Consultant
AFRY
Wrocław, Poland
Original Message:
Sent: Sun January 12, 2025 05:25 PM
From: Aneesh Joseph
Subject: Alternatives for using maxauth in API Calls in MAS9
Hi Willem
Yes MAS9 does not support basic authentication anymore. Passing a username/password is very insecure and this is why it has been removed. If you take that Base64 encoded MAXAUTH value and decode it, you will be able to get the user credentials.
I'm not sure I fully understand your requirement, but why don't you use your own identity provider for your custom app? And if it is the same identity provider that Maximo uses, then you could use SSO between your custom app and Maximo.
Cheers
------------------------------
Aneesh Joseph
Director and Solutions Architect
objec3d
Melbourne, Australia
https://www.objec3d.com
Original Message:
Sent: Fri January 10, 2025 03:33 AM
From: Willem Mullender
Subject: Alternatives for using maxauth in API Calls in MAS9
In Maximo version 7.x we would use an API call with the MAXAUTH header property in order to obtain the apikey. This apikey was then used in all further api calls.
Ie the following call would return an APIKEY.
curl --location 'http://localhost/maxrest/oslc/apitoken/create?lean=1' \
--header 'MAXAUTH: d2lsbGVtLm11bGxlbmRlcjpVVSEhbGxlbTAwVVUsLmxsZW0VwMFVVLi5sbGVtMDAc=' \
--data '{
"expiration": -1
}'
However in MAS9 this possibility is now blocked as is the use of basic authentcation. As far as I can see that leaves us with no possibility to let a user get his own apikey via username/password. This is particularly problematic when custom apps are being used in which the user has to use his Maximo credentials to log on and use the app.
Are there ways around this or are there alternatives that don't require making "safety hacks"? I know Mobile does this, but this is quite deep in the code and not easy to replicate.
------------------------------
Willem Mullender
------------------------------