Web Service Authentication failed

Hi,

We have a problem with some users that use web services to upload documents to Documentum. In the following exception's trace, the user XXXXX tries to upload a document but an authentication error occurs. We don't know why it happens because the user has been logged in before and has sessions on the pool.

Any idea??

Thanks!!

04/07/2012 08:45:07,474 DEBUG (Log4jAdapter.java, debug():71) - Authorization failed, please review identities provided in service context "temporary/127.0.0.1-1341390730701-1957450556"

com.emc.documentum.fs.rt.AuthenticationException: Authorization failed, please review identities provided in service context "temporary/127.0.0.1-1341390730701-1957450556"

at com.emc.documentum.fs.rt.impl.handler.AuthorizationHandler.authenticate(AuthorizationHandler.java:114)

at com.emc.documentum.fs.rt.impl.handler.AuthorizationHandler.handleMessage(AuthorizationHandler.java:54)

at com.emc.documentum.fs.rt.impl.handler.AuthorizationHandler.handleMessage(AuthorizationHandler.java:1)

at com.sun.xml.ws.handler.HandlerProcessor.callHandleMessage(HandlerProcessor.java:284)

at com.sun.xml.ws.handler.HandlerProcessor.callHandlersRequest(HandlerProcessor.java:135)

at com.sun.xml.ws.handler.ServerSOAPHandlerTube.callHandlersOnRequest(ServerSOAPHandlerTube.java:133)

at com.sun.xml.ws.handler.HandlerTube.processRequest(HandlerTube.java:116)

at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)

at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)

at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)

at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)

at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)

at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)

at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)

at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)

at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)

at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)

at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)

at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)

at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)

at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)

at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)

at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)

at java.lang.Thread.run(Thread.java:595)

Caused by: com.documentum.fc.client.DfAuthenticationException: Authentication failed for user XXXXX with docbase GDLIB01.

at com.documentum.fc.client.impl.docbase.DocbaseExceptionMapper.newException(DocbaseExceptionMapper.java:52)

at com.documentum.fc.client.impl.connection.docbase.MessageEntry.getException(MessageEntry.java:39)

at com.documentum.fc.client.impl.connection.docbase.DocbaseMessageManager.getException(DocbaseMessageManager.java:137)

at com.documentum.fc.client.impl.connection.docbase.netwise.NetwiseDocbaseRpcClient.checkForMessages(NetwiseDocbaseRpcClient.java:305)

at com.documentum.fc.client.impl.connection.docbase.netwise.NetwiseDocbaseRpcClient.applyForObject(NetwiseDocbaseRpcClient.java:648)

at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection$8.evaluate(DocbaseConnection.java:1239)

at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.evaluateRpc(DocbaseConnection.java:1007)

at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.applyForObject(DocbaseConnection.java:1231)

at com.documentum.fc.client.impl.docbase.DocbaseApi.authenticateUser(DocbaseApi.java:1700)

at com.documentum.fc.client.impl.connection.docbase.DocbaseConnection.authenticate(DocbaseConnection.java:404)

at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.authenticateConnection(DocbaseConnectionManager.java:161)

at com.documentum.fc.client.impl.connection.docbase.DocbaseConnectionManager.getDocbaseConnection(DocbaseConnectionManager.java:51)

at com.documentum.fc.client.impl.session.SessionFactory.newSession(SessionFactory.java:29)

at com.documentum.fc.client.impl.session.PrincipalAwareSessionFactory.newSession(PrincipalAwareSessionFactory.java:35)

at com.documentum.fc.client.impl.session.PooledSessionFactory.newSession(PooledSessionFactory.java:47)

at com.documentum.fc.client.impl.session.SessionManager.getSessionFromFactory(SessionManager.java:111)

at com.documentum.fc.client.impl.session.SessionManager.newSession(SessionManager.java:64)

at com.documentum.fc.client.impl.session.SessionManager.getSession(SessionManager.java:168)

at com.emc.documentum.fs.rt.impl.handler.AuthorizationHandler.authenticate(AuthorizationHandler.java:90)

... 37 more

Find more posts tagged with

Documentum

Comments

rohit0212

having same problem .... did u got any solution?

Axel_Gil

Not yet....

The problem still occurs. Some days it happens very frequently but others only sometimes...

I don't undarstand anything

Axel_Gil

Hi!!!

Still having this problem, but its frequency seems to have been reduced. Now, if the error occurs it is possible to establish a session after one or two tries. But normally it works fine...

EMC has told me to increase the CS max session number, but i think it isn't the cause because we have 350 max session count and never no more than 100 concurrent users.

Please i need help with this issue.

abc123

what is the DFS identity (authentication scheme) you use? A sample SOAP request is helpful to identify the cause. DFC trace also helps.

With the same username/password, does it always fail or fail sometimes?

Regards,

William

DCTM_Guru

Axel,

FYI - Webtop/WDK will instantiate more than one session per user. I dont recall why, but you should not assume total # sessions = # concurrent users. Also, sessions will persist when a user closes app for a finite amount of time, so this will impact the total # sessions as well.

Axel_Gil

Hi!!!

The case of sessions is very problematic and not sufficiently well explained anywhere. Furthermore it is not intuitive and often totally incomprehensible. I think it's a very important issue and EMC should be clearer in its documentation.

On our WS we use contextfactory to retrieve the serviceContext.

serviceContext = contextFactory.getContext();

Property parametroVERSION = serviceContext.getRuntimeProperty("VERSION");

if (parametroVERSION!=null)

{

versionCliente = parametroVERSION.getValueAsString();

}

RepositoryIdentity repoIdentity = (RepositoryIdentity) serviceContext.getIdentity(0);

try{

sessionManager = DfcSessionManager.getSessionManager();

....

With the same username/password, does it always fail or fail sometimes?

It fails only sometimes, more or less 20% of times.

I think that if the problem is the max session count parameter ther error should be something like this:

"Authentication failed because the max session count has been reached" and not "Authorization failed, please review identities provided in service context".

The username and password are taken from a client app that uses Single Sign On, so... i don't think the problem could be caused by human error at introducing credentials.

Thanks friends!!

Haroon_A

Axel_Gil wrote:...I think that if the problem is the max session count parameter ther error should be something like this:"Authentication failed because the max session count has been reached" and not "Authorization failed, please review identities provided in service context".

Authentication and Authorization are different. The latter means you do not have permission to do certain actions, which could be different that authentication.

Axel_Gil

Hi!

It seems "Authorization failed" is a kind of "Authentication Exception":

com.emc.documentum.fs.rt.AuthenticationException: Authorization failed, please review identities provided in service context

I'm still lost with this random error, i don't know why sometimes occurs and other times no... Any idea what can i do? or test? or modify?

Thanks!

bilak

Hello,

try to dump request XML (on most appservers -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true ). I think there is token in your header (token="temporary/127.0.0.1-1341390730701-1957450556 attribute in header.")

It's maybe because you changed user or password. You don't need this attribute.

cheers

Axel_Gil

Hi!!!

Last Friday the error occurred more virulent than ever before. More or less 50% of final users were denied to login. One of these users was me, and i haven't changed the password since two weeks.

I activated the authentication trace log and i see a line that is repeated for every user with the problem:

Fri Oct 26 09:26:35 2012 408000: 2828[1564] AT 1564: authenticateAgainstDirectoryServer: Either user password is empty or LDAP Bind failed return value = 49 Invalid credentials

After I restarted content servers used by DFS server where the client app connects, it seemed the error has reduced its frequency but not dissapear at all.

Now the error appears more or less four times per hour. Normally when a user tries to log in and receives the error, at the second attempt can log in fine.

It is very strange.

I have increased the max session count to 400 per CS but when we detected the critical error on friday we had no more than 60 sessions.

Thanks!!!

bilak

Hello Axel,

did you dumped the request xml? This seems to be another error. Or do you see error from your first post in logs?

What is in your LDAP? do your users log in with right credentials (case sensitive, etc?).

abc123

If DFC session exceeds the max count, the error message would be clear. I suggest you to file a service ticket to analyze your problem, providing the complete code to handle session manager in your WS. I saw you were using custom service context runtime properties, and that is a part easy to corruct the cache if not carefully designed (though from the code snippet it is still not clearly where the cause is).

Regards,

William