in order to user impersonate, the authentication token must be obtained first using an account with System administration rights. Is there any safety risk by using an account with System admin rights?
Is this a trick question?
Of course there is a security risk, you have an account that can bypass (most) Access Control Lists/security settings. Whether there is a safety risk depends entirely on what that content does/how it could be used (but I suspect you didn't really mean "safety" in the first place). Once you have setup the impersonation, you can trust that ACLs will do what they are intended to do, the switch of user context works as if you'd logged in with that user to begin with.
Leaving aside any technical risks, as the previous poster has mentioned, I would imagine there is only an issue, possibly, in keeping with the spirit of compliance, or indeed to the letter.
Impersonating X user to complete Y task is not the same as X user signing off on the review process of Y task, were it to be audited.
Some business requirements are quite stringent in that the correct procedure be followed when going through an account, like in a hypothetical workflow: reviewer -> manager -> partner sign-off -> transmission
If the manager is not available to complete their step, then doing it as them via impersonation affects trust, compliance and accountability for that account.
So, bad things can be done with the keys to the kingdom, so it's important to keep those keys under tight control.
Thank you so much Dave and Nizar for your responses. Do you have any case study on when to use impersonate and when should not?
Hi Mike
I think Nizar said it best really. Impersonation is a great tool when you need to perform tasks on behalf of another user but are not particularly concerned about audit trails. Where non-repudiation of transactions is important then impersonation is not advisable (as it essentially says that the named user did NOT do the task themselves).
On a practical sense, our application called “Criminal eFile” provides electronic disclosure to Criminal Defence Counsel – this is a paper-based process in most of Canada today. It is a requirement to provide full disclosure in a timely manner (the Supreme Court of Canada has ruled on this) thus it is vital that we be able to show that disclosure was offered and accepted in a way that will make it through a court challenge … non-repudiation, it is not possible for a Defence Counsel to deny the audit trail. We provide Defence Counsel access through a controlled portal / proxy to allow them to download the content but not otherwise have access to the system. In this circumstance, we have to log them in using their credentials or they’d be able to argue that it wasn’t them doing it.
If we didn’t care about the audit trail, we could have done this using impersonation (though I doubt we would have). Impersonation works best when you need to become another user but don’t have access to their credentials … hard for me to come up with a really good use-case for this beyond application support (so you can “see what they see”) but I’m sure other, brighter people have some ideas.
Dave
From: eLink Entry: Content Web Services Forum [mailto:otdncontentwebservices971forum@elinkkc.opentext.com]Sent: Tuesday, September 19, 2017 2:16 PMTo: eLink RecipientSubject: safty concern with Impersonate call 2
safty concern with Impersonate call 2
Posted by Hao, Mike On 09/19/2017 04:15 PM
[To post a comment, use the normal reply function]
Topic:
safty concern with Impersonate call
Forum:
Content Web Services Forum
Content Server:
Knowledge Center CS16
Hi Mike,
I’m not sure such a thing could exist as that would depend entirely on the application use case/functionality/design, so it would always be a moving target for each new dev projet. You’ll have to examine your own application requirements closely and determine whether or not using impersonation is appropriate or even necessary at all.
AK
From: eLink Entry: Content Web Services Forum [mailto:otdncontentwebservices971forum@elinkkc.opentext.com]Sent: Tuesday, September 19, 2017 4:16 PMTo: eLink Recipient <devnull@elinkkc.opentext.com>Subject: safty concern with Impersonate call 2
The typical scenario is that a user is using application MyApp and from that application you want to retrieve information in CS. When you connect to CS you need to supply the user credentials of the user that is using MyApp. They need to be in a format that CS supports like username/password, SAML token, ….
In case you don’t have such a token then the options are:
<![if !supportLists]>- <![endif]>Connect to CS as a technical user. This means that each user of MyApp will see the same or you need to implement the restriction in MyApp yourself.
<![if !supportLists]>- <![endif]>Connect to CS as a sysadmin user and that change to the same user as the MyApp user. This way all the access permissions in CS are checked against the actual user.
Some notes: Impersonation is as safe as how safe the password is of the system admin user you use. Afterwards it is as safe as CS is.
Impersonation is only possible from a user with more rights to a user with less rights. With security clearance you can give a admin user less rights than a user and therefore impersonation Is not allowed.
In case you want for you own function give a user sys admin rights then you may consider a System User. A system user doesn’t have a login account. All actions done by the system user will be audited as bedone on behalf of the actuall user.
Hans
From: eLink Entry: Content Web Services Forum [mailto:otdncontentwebservices971forum@elinkkc.opentext.com]Sent: Dienstag, 19. September 2017 22:57To: eLink RecipientSubject: [EXTERNAL] - RE safty concern with Impersonate call 2
[EXTERNAL] - RE safty concern with Impersonate call 2
Posted by Kinchlea, Dave On 09/19/2017 04:55 PM
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
