Idea: using keyring for passwords instead of config.ini file?

[ykud]

I did search and couldn't see this discussed before :)

Storing passwords in text files config.ini files is often a security challenge, so maybe we can use keyring to store it in OS credential manager instead (windows credential manager, keychain, etc)?

The impact would be that you'd have enter user's password the first time you run tm1py based script.

it can be relatively straight-forward, here's how I do it:

if config.has_option(tm1_server_name, 'user'):
    user = config.get(tm1_server_name, 'user')
    password = keyring.get_password("TM1_%s"%(tm1_server_name), user)
    if password is None:
         keyring.set_password("TM1_%s"%(tm1_server_name), user, getpass.getpass(prompt="Please input password for user %s on TM1 server %s : "%(user, tm1_server_name)))
         password = keyring.get_password("TM1_%s"%(tm1_server_name), user)

[rclapp]

We have had a lot of success writing a connection wrapper around TM1py, some of which you can find in my github. We leverage AWS Secrets Manager and/or Cognos SSO. With some clever coding you can write a method that simply takes in a servers name and admin host and logs you in.

https://aws.amazon.com/secrets-manager/

From: ykud notifications@github.com Sent: Thursday, April 30, 2020 6:40 PM To: cubewise-code/tm1py tm1py@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [cubewise-code/tm1py] Idea: using keyring for passwords instead of config.ini file? (#231)

I did search and couldn't see this discussed before :)

Storing passwords in text files config.ini files is often a security challenge, so maybe we can use keyringhttps://pypi.org/project/keyring/ to store it in OS credential manager instead (windows credential manager, keychain, etc)?

The impact would be that you'd have enter user's password the first time you run tm1py based script.

it can be relatively straight-forward, here's how I do it:

if config.has_option(tm1_server_name, 'user'):

    user = config.get(tm1_server_name, 'user')

    password = keyring.get_password("TM1_%s"%(tm1_server_name), user)

    if password is None:

            keyring.set_password("TM1_%s"%(tm1_server_name), user, getpass.getpass(prompt="Please input password for user %s on TM1 server %s : "%(user, tm1_server_name)))

            password = keyring.get_password("TM1_%s"%(tm1_server_name), user)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/cubewise-code/tm1py/issues/231, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEK7GZSSZIMBEX556CAT5LDRPISAFANCNFSM4MWZBKFQ.

[ykud]

Thanks @rclapp , sounds interesting.

My angle was more getting rid of storing passwords in config.ini files in tm1py by default, kinda 'making it easier to do the right thing' approach.

[MariusWirtz]

Hi @ykud,

Thank you for proposing this. I think keyring is the most professional approach to deal with TM1 password in TM1py. I agree we should include it.

I suppose there are different ways of how we could include keyring in TM1py. If we include keyring as a dependency to TM1py

1. we could include the code somewhere in the RestService
2. we wrap the code into a function in the Utils module

If we don't want to include keyring as an official dependency

3. we could add a "best practice" sample to tm1py-samples, how to use keyring before instantiating the TM1Service.

Not sure which option is better. I think I would favor option 3.

• We would keep TM1py "lean" and not add new dependencies
• As you mentioned in tm1cmp, keyring and pyinstaller don't go hand in hand with each other well at the moment (even though I got it to work through hacking the backend.py file, as you suggested)

What do you guys think? Any other ideas?

Cheers,

Marius

[ykud]

Hi @MariusWirtz ,

I'm all for 3, great idea. I agree that introducing more dependencies in tm1py isn't ideal and having a sample like 'here's how to use tm1py when you don't have SSO' should do the trick. And you could be doing things a lot differently, as @rclapp was saying, so why make keyring a dependency :)

All the current config.ini samples are storing passwords explicitly, we could update them with a comment like 'don't store password anywhere except for connectivity testing, look at this sample instead to do this properly' to make it easier to follow the best practice?

Funnily enough, I started looking into keyring more for storing the git credentials rather than TM1 ;-)

Cheers, Yuri

[rclapp]

Happy to share my full connectivity module if that helps.

On May 3, 2020 5:49 PM, ykud notifications@github.com wrote:

Hi @MariusWirtzhttps://github.com/MariusWirtz ,

I'm all for 3, great idea. I agree that introducing more dependencies in tm1py isn't ideal and having a sample like 'here's how to use tm1py when you don't have SSO' should do the trick. And you could be doing things a lot differently, as @rclapphttps://github.com/rclapp was saying, so why make keyring a dependency :)

All the current config.ini samples are storing passwords explicitly, we could update them with a comment like 'don't store password anywhere except for connectivity testing, look at this sample instead to do this properly' to make it easier to follow the best practice?

Funnily enough, I started looking into keyring more for storing the git credentials rather than TM1 ;-)

Cheers, Yuri

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/cubewise-code/tm1py/issues/231#issuecomment-623213549, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEK7GZS7R2LQHFA4G2WXXI3RPYGGNANCNFSM4MWZBKFQ.

[rclapp]

I would also add that we baked in things like user/server whitelists to ensure dev accounts don't hit prod. We also added a. }Clients attribute called "allow python access" to help manage unwanted connections.

On May 3, 2020 5:51 PM, "Clapp, Ryan" rdclapp@amazon.com wrote: Happy to share my full connectivity module if that helps.

On May 3, 2020 5:49 PM, ykud notifications@github.com wrote:

Hi @MariusWirtzhttps://github.com/MariusWirtz ,

I'm all for 3, great idea. I agree that introducing more dependencies in tm1py isn't ideal and having a sample like 'here's how to use tm1py when you don't have SSO' should do the trick. And you could be doing things a lot differently, as @rclapphttps://github.com/rclapp was saying, so why make keyring a dependency :)

All the current config.ini samples are storing passwords explicitly, we could update them with a comment like 'don't store password anywhere except for connectivity testing, look at this sample instead to do this properly' to make it easier to follow the best practice?

Funnily enough, I started looking into keyring more for storing the git credentials rather than TM1 ;-)

Cheers, Yuri

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/cubewise-code/tm1py/issues/231#issuecomment-623213549, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEK7GZS7R2LQHFA4G2WXXI3RPYGGNANCNFSM4MWZBKFQ.

[MariusWirtz]

Hi @ykud, I like it. I will update the tm1py-samples project as you suggested!

Hi @rclapp, that would be great. We could include it as a tm1py-sample or wrap it into the Utils module if is generic enough.

[scrumthing]

@rclapp wow that sound sophisticated. Would like to dive deeper into that. The idea for the client property is great. How exactly did you do it?