Environment:
MFP 6.3 Studio Windows 7
MFP 6.3 Server (WAS LC)
Downloaded the form-based sample from the IBM MobileFirst Platform Developer Center.
In MFP 6.3 Studio, the sample runs fine.
I then change my build settings and Build All Environment -> get the new wlapp file.
I get my war file from the MFP 6.3 Server. Open up and put in the modified authenticationConfig.xml
Basically it's just transferring the one snippet from the studio authenticationConfig.xml to the xml file within the WAR file.
<customSecurityTest name="DummyAdapter-securityTest">
<test isInternalUserID="true" realm="SampleAppRealm"/>
</customSecurityTest>
I restart the server and deploy the .wlapp and .adapter files.
In the standalone server, I run the preview mode. I Enter the username and password and login. It didn't login and I see these errors on the server console.log.
[ERROR ] SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:BasicRegistry/demo.
[ERROR ] SRVE0232E: Internal Server Error. Exception Message: [com.ibm.ws.webcontainer.webapp.WebAppErrorReport: com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException: SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:BasicRegistry/demo.
at com.ibm.ws.webcontainer.session.impl.HttpSessionContextImpl.checkSecurity(HttpSessionContextImpl.java:686)
at [internal classes]
at com.worklight.core.auth.impl.AuthenticationFilter.associateAuthContextWithThread(AuthenticationFilter.java:426)
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:145)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
Caused by: com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException: SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:BasicRegistry/demo.
... 7 more
]
[ERROR ] SRVE0777E: Exception thrown by application class 'com.worklight.core.auth.impl.AuthenticationContext.checkAuthentication:604'
com.worklight.server.auth.api.WorkLightAuthenticationException
at com.worklight.core.auth.impl.AuthenticationContext.checkAuthentication(AuthenticationContext.java:604)
at com.worklight.core.auth.impl.AuthenticationContext.processRealms(AuthenticationContext.java:469)
at com.worklight.core.auth.impl.AuthenticationContext.pushCurrentResource(AuthenticationContext.java:443)
at com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:75)
at com.worklight.integration.services.impl.DataAccessServiceImpl.invokeProcedureInternal(DataAccessServiceImpl.java:430)
at com.worklight.integration.services.impl.DataAccessServiceImpl.invokeProcedure(DataAccessServiceImpl.java:139)
at com.worklight.gadgets.serving.handler.BackendQueryHandler.getContent(BackendQueryHandler.java:95)
at com.worklight.gadgets.serving.handler.BackendQueryHandler.doPost(BackendQueryHandler.java:56)
at com.worklight.gadgets.serving.GadgetAPIServlet.doGetOrPost(GadgetAPIServlet.java:148)
at com.worklight.gadgets.serving.GadgetAPIServlet.doPost(GadgetAPIServlet.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1240)
at [internal classes]
at com.worklight.core.auth.impl.AuthenticationFilter$1.execute(AuthenticationFilter.java:217)
at com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:76)
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:222)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
After studying the securityIntegrationEnabled="false workaround, I think I have figured out why things are working / not working.
The solution is actually very simple without changing the server.xml.
When the error SESN0008E occured, I was testing the FormAuth app using the common preview mode by clicking on the link from the admin console in the standalone server. Although the common preview link opened to a new browser, but the sessionID actually stays. Both browser tabs are in the same session (I checked).
It means that the sessionID that I am using is actually the one that was already authenticated by the Admin Console. And in my preview mode I tried to authenticate again in the session that was already "owned" by another user. This causes WAS to throw the error SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:BasicRegistry/demo. My app preview is in the same httpsession as the admin console, and hence the error.
So to get it to work, I copy the preview link. Close all the browser to ensure the sessions are killed. Open a new browser, paste the preview link and the FormAuthentication works now.
A maybe more convenient solution would be to create a mobile web environment and use that for preview testing.
In WAS and WAS Liberty profile, security integration is enabled by default. This also means that:
... session management facility associates the identity of users with
their HTTP sessions. This feature will mark a session as "owned" by
the first user that accesses a session that is not already marked as
owned.
If a session is already marked as owned, it will check that
the owner is the same as the current user. If not, rather than
granting access to the session, at minimum a message with identifier
SESN0008E will be logged and access to the session will not be
granted.
In some cases, an UnauthorizedSessionRequestException is
thrown, with message SESN0008E as the cause.
In the MobileFirst Development Server in Eclipse, the underlying WAS Liberty's server.xml has this disabled.
For your POC as a workaround, you can disable the feature by adding in the server.xml file the following entry: <httpSession securityIntegrationEnabled="false"/>
Note that adding this setting is global to all applications and can impact negatively on existing applications on the server, if in existance.
Related
After installing patch 10.3.6.0.200114, Weblogic console could not log in, indicating "WebLogic Server has rejected this user name or password. Please try again. " However, the service can be accessed normally
There is a bug in this PSU which prevent web app like the admin console to authenticate users. Oracle published a patch to correct this issue : SU Patch [EIL8]: 10.3.6.0.200114WLSPSU Overlay: CANNOT LOGIN TO CONSOLE, BUT CAN LOGIN TO EM WITH THE SAME USER
Download it from MOS and patch your WebLogic server installation.
I'm using sonar 5.6 LTS with LDAP plugin 2.1.0.
The basic LDAP configuation is working fine. Sonar can connect to LDAP (in my case active directory). sonar.log:
Test LDAP connection on ldaps://ldap.mycompany:636: OK
My user mapping is
ldap.user.baseDn=OU=Users,OU=Accounts,DC=mycompany
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
When I try to login with mycompany\tobi sonar logs:
DEBUG web[o.s.p.l.LdapUsersProvider] Requesting details for user mycompany\tobi
...
DEBUG web[o.s.p.l.LdapUsersProvider] User mycompany\tobi not found in <default>
This makes sense as sAMAccountName contains the value tobi and not mycompany\tobi. But when using just tobi as login, sonarqube does not connect to LDAP for authentication. I just get "Authentication failed" and the log file contains only
DEBUG web[http] POST /sonar/sessions/login | time=235ms
Any ideas why sonarqube does not always use LDAP? Thanks, Tobi
Thanks to Godin, I've finally found the answer:
The root cause is that I had a local account with the same login credentials before using LDAP. When removing users using the web interface, they are not removed permanently from the database. Instead, they are just deactivated.
I connected to the (postgresql) database and in the users table there were still all old local accounts. So I just changed the login column of all deprecated local accounts with
UPDATE users SET login='username_local' WHERE login='username'
As those accounts are deactivated, they cannot be used to login into sonarqube but should not be removed as some other tables might still have references to them.
We are running Glassfish 3.1.2.2 authenticating against an Active Directory realm. Authentication works correctly the vast majority of the time, but occasionally, authentication will suddenly start failing for all users, and we'll see errors like this in the server log:
[#|2014-03-19T21:37:32.331+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.web.security|_ThreadID=1098;_ThreadName=Thread-2;|WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: Failed file login for jeff.|#]
Note that the error message is failed file login. It appears as if Glassfish is occasionally reverting back to the file realm rather than the active directory realm.
When this problem happens, after a short time without any intervention on our part, authentication will suddenly start hitting Active Directory again and users will be able to login again.
Any ideas why Glassfish would occasionally revert to authentication against the file realm when we've configured it to use Active Directory? Should I delete the file realm altogether?
I finally determined the trigger for this. We had been connecting JVisualVM to our Glassfish instance to monitor performance. Everytime I connect JVisualVM (over JMX connection using Glassfish admin credentials), Glassfish immediately reverts to using the file realm instead of the LDAP realm. I have no idea why JVisualVM would cause this behavior in Glassfish, but it is consistently reproducible. The only workaround I have discovered is:
Disconnect JVisualVM.
In Glassfish admin console go to -> Configurations -> server-config -> Security
Change default realm (to anything other than LDAP realm), Save.
Change default realm back to LDAP realm, Save.
Clients should now again be able to authenticate against LDAP.
We've been trying without much success to enable LDAP user authentication for the Worklight Application Center. We've carefully followed the instructions here:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
First, we created the LDAP repository in the WAS console and added it to the federated repositories config:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fappcenter%2Fc_ac_was8_ldap.html
Then we configured the LDAP authentication for users and groups following:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
Finally we enabled ACL management with LDAP as suggested by:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
After the server restart these are the results:
Worklight Console: Works OK.
Application Center: Shows a ?????? in the user space with the following error in every screen related to users: FWLAC0401W: No user appears to be logged, check the Application Center security configuration.
Worklight WAS Console: We are locked out. The LDAP users do not work, the initial worklight/worklight user does not work. The only way to get in is changing the security.xml for the instance to get back in and rollback the security changes.
What are we doing wrong?
Is there a more "tutorial like" documentation to accomplish these tasks, we might be making some mistakes following the infocenter.
About the application center effect: Technically, the message means that the Web Security Context does not contain a principal (i.e. a user name). In general, Application Center must be configured so that the login screen appears (is this the case for you?).
I know two possible reasons:
Application Security is disabled in WAS. Open the WAS console and select Security > Global Security. Ensure that "Enable Application Security" is checked. Ensure also that "Enable Administrative Security" is checked.
The appcenteradmin role is mapped to special subject "Everyone". Both the appcenteradmin role and the appcenteruser role cannot be mapped to this special subject, because it simply disables the authentication and hence the security context does not know anymore which user is logged in. Look in Applications > Application Types > WebSphere Enterprise Applications > AppCenter > Security Role to user/group mapping. Here you can see how the roles are mapped and you can change it.
Since you also have a problem with the Worklight WAS console, I would guess that your situation is 1., since 2. is local to the Application center and does not affect the WAS console.
why this error comes?
I am using windows authentication. But i am getting error
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
can any one help me in this how to solve this problem?
Most likely it means you're trying to connect from an impersonated context and you did not set up constrained delegation. See Manage Kerberos Authentication Issues in a Reporting Services Environment for details and troubleshooting.
First of all, I always prefer to use the 'impersonation' settings in the ISS configuration that do not set the user/password in the web.config. Everything was fine in the QA environment, but then I passed to the production environment and some options of the web site in production started to show the 'Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error.
The issue was that I copied the web-site configuration from the QA server, using the 'Save configuration to a file' option in IIS6 while creating a brand new Application Pool in the production server.
After several hours trying to solve this error, I just deleted the Application Pool, and used the 'Save configuration to a file' option to copy the Application Pool configuration and then restored it to the new server.
If you copy the web-site configuration, also copy the Application Pool configuration. That solved my problem, without changing anything about the authentication method, the database or the web-site itself.
Reporting Setup:
I had a report accessing datasource A, with a subreport which accessed datasource B.
The report connections were set to use Integrated Security.
From my development machine:
The "main" report would run perfectly fine from my development environment (as it was running everything as me.)
From the server:
I was able to execute the subreport directly, with no problem.
The main report would run, with the text "Error: Subreport could not be shown."
Actual Problem:
The subreport was executing under the NTAUTH\ANON user, because it was the Reporting Services code which was calling the sub-report. This error was in the SSRS Logs:
System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Solution:
Set up the sub-report data connection to execute using a SQL User login.
Only grant that user execute on the particular procedure you're calling for the report.
This allowed me to get the report working without involving other departments that controlled the application servers (modifying web.configs or IIS configurations)