Connect to TM1 Cube from Linux when SSO or CAM Passport is Required?

[dlvond1]

All,
We had a python script running in Openshift (RedHat Linux image) for a couple years, passing in a service account ID and password in the connection string to gain access. The administrators of the TM1 Cube changed the security so that SSO is required. So now I can only run it from a Windows machine. We have found if we go grab the passport/token value from the web console on a windows machine we can use that token to connect/pull data in our openshift instance, but it has a very fast expiration date.

I'm trying to see if it is possible to 1) programmatically access/grab the passport/token and then use it in the connection string from Linux/Openshift OR 2) Get a passport/token that does not expire?

I realize one (or both?) of these might not strictly have to do with TM1py, but we have as of yet been unable to figure out a solution for this. I have asked these same questions to our TM1 Support folks and they have been unable to give an answer as they do not support TM1Py :(.

[MariusWirtz]

Hi,

Yes. The SSO (TM1's IntegratedSecurityMode 3) only works on a windows machine.

I think the validity of the token (session-id) is determined by HTTPSessionTimeoutMinutes parameter in the tm1s.cfg.
However, this token will not "survive" a TM1 server restart.

So even if you keep your session alive through regular interaction between py and TM1, eventually after a server restart (typically on the weekend) the python script requires a new token.
So in other words: every token expires eventually.

However, here is an idea:
If you can manually connect with TM1 through the web browser and grab the token, you could also automate it with Python :)
You could use headless chrome selenium with Python to access TM1Web and grab the session token. Then hand over the session token to TM1py and use it.

I hope this helps

[dlvond1]

Thanks for your reply..I thought about doing this as being a "quick and dirty" option..I just need to find someone on our team who knows how to do it...conceptually it sounds simple...access the site and grab the contents of the token, then pass that to the TM1 Connection string..BOOM. But trying to translate it to actual usable code is extremely frustrating at my level :).

We have no privileged access to the TM1 server so I don't think we would be able to change the HTTPSessionTimeoutMinutes in the tm1s.cfg file unless I'm missing something (i searched my codebase and tm1py module code and don't see this as an option)

[MariusWirtz]

I understand.

regarding the HTTPSessionTimeoutMinutes, if a TM1 user has admin permissions, you can update the tm1s.cfg using TM1py. here is a sample.

from TM1py import TM1Service

params = {
    "address": "",
    "port": 8010,
    "user": "admin",
    "password": "apple",
    "ssl": True
}

with TM1Service(**params) as tm1:
    config_changes = {
        "Access": {
            "HTTP": {
                "SessionTimeout": "P0DT12H00M00S"
            }
        }
    }
    tm1.server.update_static_configuration(config_changes)

[rkvinoth]

When you say changed the security so that SSO is required, I'm assuming that they changed the password and not providing it for security reasons.

Anyway, you could potentially create two services. Service 1 would be running in Windows and Service 2 would be running in Linux.

Service 1's responsibility would be to create a session using SSO and populate the passport in some secure web service (like AWS Secrets Manager). The service will continue to ping the TM1Server every n minutes to not get logged out. If logged out, create a new session and refresh the passport in the web service.
Service 2's responsibility would be to retrieve that passport and perform other tasks. If the passport isn't valid, retry the retrieval after n minutes.

[dlvond1]

I don't know exactly what was changed...we used to be able to pass in the username and password of a service account that had access to the views we needed, but at some point that was no longer allowed. The service account was used because it had read access to the views we needed, it was not a privileged account that could make changes to the TM1 Servers configuration.

This is an interesting idea though..perhaps we could have some azure function grab the token and store it in the keyvault we are already using for other credentials (service account, database credentials, etc.). Ideally if we're just grabbing the token we would be able to do that directly from the python script that's already running.

One other detail I didn't mention in the original post...this is a job that runs for maybe 10-15 minutes once a week...so we would only need to retrieve a token once prior to connecting to TM1 and then let it expire naturally after 20 mins until the next run a week later.

[zsoltmoravcsik]

3rd option for you to implement the Kerberos SSO in Linux in the python code, that solves it as well.

…

On 2023. Mar 6., Mon at 18:08, Vinoth Kumar Ravi ***@***.***> wrote: When you say *changed the security so that SSO is required*, I'm assuming that they changed the password and not providing it for security reasons. Anyway, you could potentially create two services. Service 1 would be running in Windows and Service 2 would be running in Linux. *Service 1's* responsibility would be to create a session using SSO and populate the passport in some secure web service (like AWS Secrets Manager). The service will continue to ping the TM1Server every *n* minutes to not get logged out. If logged out, create a new session and refresh the passport in the web service. *Service 2's* responsibility would be to retrieve that passport and perform other tasks. If the passport isn't valid, retry the retrieval after *n* minutes. — Reply to this email directly, view it on GitHub <#859 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHNEK3DDLSVLKKTTWWW2HWDW2YKZTANCNFSM6AAAAAAU6IZ7DA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dlvond1]

In Openshift there is a Kerberos Sidecar that I'm told could possibly be used...but no one internal to our company has been able to actually show us how it would work in reality..so we pivoted to the passport/token method.