ImpersonateUser Method

Given the following code:

String newToken = changeUser("someUser", token);

fOTAuth = new OTAuthentication();
fOTAuth.setAuthenticationToken( newToken );

Why do we get the first user as the one who executes actions, and not the impersonificated one?

Is there something that we are missing?

_________________________________________________________

    public String changeUser(String userName, String token)
   {

       String serviceURL = "http://ETC:8080/les-services/services/Authentication";
       String username = userName;
       String newToken = null;

           try
           {
               newToken = WebServiceUtil.getImpersonateUser(new URL( WebServiceUtil.getServiceLocation( serviceURL, "Authentication" ) ), token, username);

           }
           catch ( Exception ex )
           {
               System.out.println( ex.getMessage() + "Error" );
           }

       return newToken;

   }

_________________________________________________

    public static String getImpersonateUser( URL location, String token, String userName) //added
   throws Exception
   {
       Authentication endpoint = getAuthenticationService( location );
       setSoapHeader( (WSBindingProvider) endpoint, token );
       return endpoint.impersonateUser(userName);
   }

Find more posts tagged with

Comments

Guy_Pomerleau

If you are running .net, by default "impersonate" in the web.config is false so the credential of the caller are not passed. Impersonate, need to be set to true

Appu_Nair1

Impersonation as it says allows you to "impersonate".It is available in OS's windows,unix
and in many other things so it is not something that OT designed by accident.
In livelink to impersonate "Tom" by a livelink user called "****" ,'****' needs to hold the "SA" (System) priv in
their login.That is the absolute condition that OT imposes.Both actions are audited as well.
You will see examples of OT products that uses "impersonation" in some examples as in xECM(SAP),Sharepoint Integration,LAPI et al
A programming language may not be able to do livelink webserver/Domain Controller/AD/LDAP/OTDS for domain
based authentication(True way of doing Single Sign On) as easily as a user's browser so in applications to create a pass thru.
Nobody is forcing you to use a authentication token other that for a real user.Consider impersonation
a bonus for stuff you may want to do.If you can make your livelink webservices code work in a SSO situation many times this is not needed
David Templeton recently was saying about OT's thought that a separate class of user could be created who could
not login to livelink.A SA'ed userid has unhindered access to livelink everywhere so we audit any SA id's and
basically make it difficult for anybody not to misuse their extra privileges

Quoted Pedro Miguel Neto on 2013-04-02 16:51:

Given the following code:

String newToken = changeUser("someUser", token);

fOTAuth = new OTAuthentication();
fOTAuth.setAuthenticationToken( newToken );

Why do we get the first user as the one who executes actions, and not the impersonificated one?

Is there something that we are missing?

_________________________________________________________

_________________________________________________

Quoted Pedro Miguel Neto on 2013-04-02 16:51:

Given the following code:

String newToken = changeUser("someUser", token);

fOTAuth = new OTAuthentication();
fOTAuth.setAuthenticationToken( newToken );

Why do we get the first user as the one who executes actions, and not the impersonificated one?

Is there something that we are missing?

_________________________________________________________

_________________________________________________

Pedro.Neto

We are using Java.

Pedro.Neto

Hello, Appu

We know that only a user with that specific permission can, indeed, do the impersonate. We tested our code with the Admin user, and still can't do what is expected.

Sorry, I didn't fully understood what you said about not needing the authentication token. Can you please elaborate?

Best Regards

Pedro Neto

Quoted Appu Nair on 2013-04-10 18:21:

Quoted Pedro Miguel Neto on 2013-04-02 16:51:

Given the following code:

String newToken = changeUser("someUser", token);

fOTAuth = new OTAuthentication();
fOTAuth.setAuthenticationToken( newToken );

Why do we get the first user as the one who executes actions, and not the impersonificated one?

Is there something that we are missing?

_________________________________________________________

_________________________________________________

Quoted Pedro Miguel Neto on 2013-04-02 16:51:

Given the following code:

String newToken = changeUser("someUser", token);

fOTAuth = new OTAuthentication();
fOTAuth.setAuthenticationToken( newToken );

Why do we get the first user as the one who executes actions, and not the impersonificated one?

Is there something that we are missing?

_________________________________________________________

_________________________________________________

Appu_Nair1

I do not do any Enterprise Library services programming.If your coding infrastructure depends on RCS based things I do not understand that.In regular livelink to do anything you need a userid/password.With that you will only be able to manipulate objects to which your userid has access.When a program does impersonation it uses a technical(Sysadmin) user to get a session into livelink and do it on the user's behalf so when you look at the object it may say the "impersonated user" did it.So first tell the forum your setup people who are knowledgeable more in that will guide you.Livelink's web services which we call "standalone" is called CWS/EWS they can run on Tomcat as well as IIS.Livelink's webservices standalone are akin to a user logging into livelink and doing what needs to be done with a programming language.You cannot impersonate unless the first session creator is a Sysadmin.If I wrote a webservices client for a user in my company I will make him log on and lead him to a area where his userid has permissions.The token returned in that is encrypted info about the usr so on subsequnet hits he does not need to re-authenticate .

Other people will help if you can let them know what the utimate intention is.RCS(ELS) introduces complexities such as an 'application' entry point etc.These are not known to CWS at least not directly .RCS has a bunch of examples as well

Appu_Nair1

BTW seeing your URl

String serviceURL = "http://ETC:8080/les-services/services/Authentication";

it looks to me like standard webservices are in play here

If so if you put Debug=2 ,wantlapilogs=true,wantlogs=true in your opentext.ini and re-start when you make a WS call from your client on the livlink server logs you will see a inargs/outargs stuff.That way you can se if your call is even reaching livelink or you are gtting into some patch/code/revision issues

I am attaching a link for you to see if you can yourself do some poking around

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=34399600&objAction=download

This document has sample code in C# which is almost akin to Java.I do not have a java env handy right now but the server side logs should be common.If you do not see 'Impersonateuser' call in livelink server side logs it is better to ask OT support and see if you are missing anything.In any case the logs will tell you one way or the other.My env is an old LL9.7.1 Update 2.