Maximo

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

And what about the security of MBO querying via REST?

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

And what about authorizing API-Routes? 

Do we need to configure each object type for the route-separated security configuration?

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

I want just to add for all that Steven wrote, that there is property mxe.oslc.validusewith, where u can determinate what OS types can be used by OSLC handler. 

For example, exclude REPORTS to have less work. 

By the way, it will be interesting, why out of the box, REPORTS objects include here 

Steven ? :-) 

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

------------------------------
Steven Shull

Original Message:
Sent: Fri October 07, 2022 07:45 PM
From: Pankaj Bhide
Subject: OSLC JSON Rest API - Security

Hello,

Can someone please explain or share some documentation on how the "security model" works with OSLC JSON Rest API? 

We presently have a user that is placed in the "maxadmin" group (that have almost all the privileges). We created the APIKeys of that user and we are using those API keys for HTTP Get/Post requests for exchanging the data with other external applications. We were wondering to use another user  (from a different security group) that may have only "limited privileges". However, today I was surprised to see the following:

1) We created a group that has "least privileges" (it does not have even read privilege for wotrack, asset etc.)
2) We created a user that belongs to 1)
3) We created the APIKeys for 2)
4) Now we wanted to test the HTTP Get/Post using that the APIKeys generated in 3) to see whether the security model will restrict us or not.

We were surprised to see that we were able to retrieve the data from almost all the object structures; we were infact able to perform HTTP Post to insert/update the rows in the underlying MBOs using those APIKeys. 

How do we  control the access privs for this above? 

We are also executing the automation scripts via HTTP Post using OSLC JSON Rest API. How do we control that as well?

------------------------------
Pankaj Bhide
Computer Systems Engineer
Berkeley National Laboratory
Berkeley CA
------------------------------



#MaximoIntegrationandScripting
#AssetandFacilitiesManagement
#Maximo

Hi Steven

I am not very understanding how to configure which user have permission to the script, since it only configured two variables, but how the script determine it and how to graent access to users or security group, can you elaborate more on it.

Thanks

Jason

Original Message:
Sent: Mon October 10, 2022 08:47 AM
From: Steven Shull
Subject: OSLC JSON Rest API - Security

For object structures, long term you should look at enabling the system property mxe.int.enableosauth. This was disabled by default in upgraded environments and enabled by default in new instances, but I believe we're looking to enable it by default in all environments. Before you can enable this though, you need to go through and identify all object structures that you utilize and ensure that they have security configured in the Object Structures application. For example, MXASSET out of the box has no security configured (Authorization name is empty) which means that any authenticated user can utilize the object structure. 

Utilizing the "Configure Object Structure Security" action, you can either tie the authorization name to an application (such as ASSET) or you can configure unique permissions for that object structure (which is what I would recommend). To configure unique security permissions for the object structure, check the "Use Object Structure for Authorization Name" checkbox in the dialog.

If you enable the system property before configuring this on each of the object structures, those object structures will not be usable. This includes all integration methods (file, table, SOAP, REST, etc.) for all users (including MAXADMIN/MXINTADM). That's why it's very important you identify each object structure currently being used and ensure this is configured. This could impact third party mobility products as well. 

If the automation scripts are actions on the object structure, you can secure them by tying an option name to the action. 

If you're calling scripts using the script handler (/maximo/oslc/script or /maximo/api/script) then it's not well documented but there are ways to secure it. The first is you can tie an application & option to the script route handler (using the Add/Modify API Routes dialog in the Object Structures application). This blocks any user from calling a script that doesn't have the permission defined. Most users don't need to call automation scripts via the REST API so this alone may be sufficient.

If you need more granular permission control (IE you can run script A but not script B), on the scripts you can add two variables (authapp & authsigoption). This will check these permissions for this specific automation script. If you don't have these variables, any user can use them. 

------------------------------
Steven Shull

Original Message:
Sent: Fri October 07, 2022 07:45 PM
From: Pankaj Bhide
Subject: OSLC JSON Rest API - Security

Hello,

Can someone please explain or share some documentation on how the "security model" works with OSLC JSON Rest API? 

We presently have a user that is placed in the "maxadmin" group (that have almost all the privileges). We created the APIKeys of that user and we are using those API keys for HTTP Get/Post requests for exchanging the data with other external applications. We were wondering to use another user  (from a different security group) that may have only "limited privileges". However, today I was surprised to see the following:

1) We created a group that has "least privileges" (it does not have even read privilege for wotrack, asset etc.)
2) We created a user that belongs to 1)
3) We created the APIKeys for 2)
4) Now we wanted to test the HTTP Get/Post using that the APIKeys generated in 3) to see whether the security model will restrict us or not.

We were surprised to see that we were able to retrieve the data from almost all the object structures; we were infact able to perform HTTP Post to insert/update the rows in the underlying MBOs using those APIKeys. 

How do we  control the access privs for this above? 

We are also executing the automation scripts via HTTP Post using OSLC JSON Rest API. How do we control that as well?

------------------------------
Pankaj Bhide
Computer Systems Engineer
Berkeley National Laboratory
Berkeley CA
------------------------------



#MaximoIntegrationandScripting
#AssetandFacilitiesManagement
#Maximo