Skip to main content

Hi,

 

As the title, I have a database where I have put in database coloumn level encryption on some tables. I have a written a custom service object which then gets the data out of that and then puts it out in a smartobject. Now, I have locked down who can or cannot see the data in the database Level. My issue now, is that since the data comes out in a unencrypted form through the actual smartobject and currelty I see so way of control who can execute that smartobject. Is there a way forexample for e to say, this service account can execute thsi smartobject. No one else, not even the system administrator can execute this smartobject.

 

Thanks in advance. If this is not possible, do you guys and gals have any workaround ideas while using smartobjects and smartforms. 

I might not be understanding the whole problem but what if you just set the service instance authentication to Impersonate and then only provide the service account permissions at the database level. That would effectively mean that only the service account could execute the SmartObject. 

Thank you very much for your reply. This looks promising. So what is the exact difference between impersonate and service account in K2. Would you be able to provide me asome more information on this.

Service account uses the K2 service account credentials when interacting with the underlying service instance.

 

Impersonate passes the currently logged in user's credentials when interacting with the underlying service instance.

 

Therefore, if you have a smartobject based on SQL, and say, denallix/bob has permissions on the table we're looking at, any workflow executed by bob will be fine, as he has permissions on the table.  Further, SQL logs will show bob as the user who made the change.


If denallix/sally comes along and clicks "OK" on a form that calls the same smartobject, and doesn't have permissions, when the smartobject is fired and passes her credentials to SQL, it will fail, as she doesn't have permissions on the DB.  SQL logs will show that sally tried to do something and was prevented from doing so.

 

Under the service account context, both users would be able to execute the smartobject, update SQL, and the SQL log will show "denallix/k2service" as the user responsible for the change.

 

Some docs that may be relavent:

 

http://help.k2.com/onlinehelp/k2blackpearl/devref/current/webframe.html#how_to_use_impersonate_user_using_the_k2_api.html

https://help.k2.com/onlinehelp/k2blackpearl/userguide/current/webframe.html#sic02.html

Impersonate will cause the user's credentials to be passed and authenticated by the end data source (sql in your case).  So if Bob executes the smartobject it would pass Bob's credentials to SQL and SQL would determine if Bob has access to that SQL database.

 

If you choose the service account for the service instance it means that anyone could execute the smartobject and it would use the service account permissions to actually perform the query.  So assuming that the service account has been given permissions to the SQL database then anyone who has access to execute the SmartObject would be able to execute it because the service account has permissions to sql.

 

Hope that helps.

Tim

Thanks you very much for your replies timkin and mike. You guys have explained it very clearly. My issue doesnt seem to match both weirdly. If I have impersonate, it means  would have to add every user who uses the forms to the database membership which would be very difficult to maintain as it can be a lot of users. If I use service acount then anyone can execute the smartobject including anyone who can get onto the servers. It seems to be a case of if I want to include or exclude, and both would be a maintainance problem. At the moment, i think I will go with the inclusion method and use the impersonate.   

 

Just wondering, purely fromt the smartobject tester point of view. I already control who is authorised to access the smartforms. I just dont want any of the admins to run the smartobject through the smartobejct tester. Is it possible to hide this smartobject from the tester. I am aware that anyone who has admin rights will be able to use the K2 api to execute this smartobject through a bit of code but is it possible to hide it form the tester.  

Hi s0m3one,

 

I can't think of a way you can hide smartobjects from the service tester, as the tool is designed to display everything that K2 can "see" so to speak.  That being said, I think NTFS permissions might help you here, as instead of hiding the instance in the tester, you could restrict access to the folder, (and it's contents) via NTFS permissions.

 

Removing execute permissions, or setting an explicit deny on executing the smartobject tester .exe for users who do not have a business purpose sounds like a reasonable solution.

 

11661i213B742DDE474C8B.png


Regards,

 

Mike

Thanks Mike. However, the evironment is shared at the moment betwweeen different departments. The other departments will still require access to the smartobject tester tool for the work they do on their side. Its a very useful tool for debugging erroring processes and debuggin failed deployments. Unfortunatley, we cannot define if they should have access to the tool itself at the moment.  

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings