Setup Page accessable after setup (#29)

Activities

Daniel Wisnewski opened 8 years ago

Due Date
2016-07-14

Currently, the setup page is available after first-setup, allowing for possible configuration changes from unauthorized users.

We should provide a means to protect the /setup/ pages after new server setup.

Possible options:

Allowing access only from localhost, however this could cause some setup issues.
Use ad-hoc commands to open/close access.
Allow any entity to use setup pages, but lock access to localhost after first setup is finished.
Require API-Key or additoinal parameter to access page after first setup.
set a flag in init.properties, allow locking from option in /setup/.
other restrictions allowing only certain logins/names to access.

Andrzej Wójcik (Tigase) commented 8 years ago

%kobit Which option we should use? Or maybe we should protect this page in other way?

Andrzej Wójcik (Tigase) commented 8 years ago

Summary of discussion from MUC room.

We need to:

Check function for loading configuration from file
Add request for username/password before allowing to access setup page (stored in init.properties file)
Add default username/password to provided default configuration file
Add request to pass new username/password during first setup (if not passed will lock access to setup after restart)

Andrzej Wójcik (Tigase) commented 8 years ago

I reworked this authentication mechanism, however I slightly changed our decisions as I found that protection mechanism was implemented in task #2101. So I merged our ideas from both tasks.

Here is how it will work:

You can access setup page using username/password stored in etc/init.properties file

Value is stored in entry with key http/setup/admin-credentials where value is in form username:password which in default file shipped with Tigase XMPP Server is set to admin and @tigase@. So entry in file is:

http/setup/admin-credentials=admin:tigase

If authentication repository is accessible you can access page by providing jid which is listed in --admins property and matching password

I decided to support this as code was already in place.

Default username is admin and password is tigase@. If this are found in @init.properties file then setup will not fill form used for setting username and password for setup security with values. This will force user to set custom values or setup will be locked if there will be no access to authentication repository.

%kobit Do you agree on this mechanism or I should change it? If you agree pass this task to %daniel so he could test it and update documentation.

Artur Hefczyc commented 8 years ago

Looks good to me, Daniel please proceed with documentation for this.

Daniel Wisnewski commented 8 years ago

Hi Andrezej, I want to run a few things by, the setup is not 100%, unless we want to change our approach.

A few scenarios I ran with the new system.

Scenario 1: Setup Page access is granted to admin created during DB setup: This works OK, however I do get an error from Tigase:

| 2016/06/27 15:37:08 | 2016-06-27 15:37:08.023 [pool-10-thread-1]  DummyServletRequest.getUserPrincipal()  SEVERE: null
| 2016/06/27 15:37:08 | tigase.db.UserNotFoundException: User does not exist: admin, in database: jdbc:derby:tigasedb;create=true
| 2016/06/27 15:37:08 | 	at tigase.db.jdbc.TigaseCustomAuth.userLoginAuth(TigaseCustomAuth.java:970)
| 2016/06/27 15:37:08 | 	at tigase.db.jdbc.TigaseCustomAuth.plainAuth(TigaseCustomAuth.java:653)
| 2016/06/27 15:37:08 | 	at tigase.db.AuthRepositoryMDImpl.plainAuth(AuthRepositoryMDImpl.java:194)
| 2016/06/27 15:37:08 | 	at tigase.http.setup.SetupModule$1.checkCredentials(SetupModule.java:105)
| 2016/06/27 15:37:08 | 	at tigase.http.java.DummyServletRequest.getUserPrincipal(DummyServletRequest.java:400)
| 2016/06/27 15:37:08 | 	at tigase.http.java.DummyServletRequest.isUserInRole(DummyServletRequest.java:378)
| 2016/06/27 15:37:08 | 	at tigase.http.setup.SetupServlet.processRequest(SetupServlet.groovy:77)
| 2016/06/27 15:37:08 | 	at tigase.http.setup.SetupServlet.service(SetupServlet.groovy:66)
| 2016/06/27 15:37:08 | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
| 2016/06/27 15:37:08 | 	at tigase.http.java.RequestHandler.handle(RequestHandler.java:96)
| 2016/06/27 15:37:08 | 	at com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
| 2016/06/27 15:37:08 | 	at sun.net.httpserver.AuthFilter.doFilter(Unknown Source)
| 2016/06/27 15:37:08 | 	at com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
| 2016/06/27 15:37:08 | 	at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(Unknown Source)
| 2016/06/27 15:37:08 | 	at com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
| 2016/06/27 15:37:08 | 	at sun.net.httpserver.ServerImpl$Exchange.run(Unknown Source)
| 2016/06/27 15:37:08 | 	at tigase.http.java.JavaStandaloneHttpServer$ExecutorWithTimeout$1.run(JavaStandaloneHttpServer.java:192)
| 2016/06/27 15:37:08 | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
| 2016/06/27 15:37:08 | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
| 2016/06/27 15:37:08 | 	at java.lang.Thread.run(Unknown Source)

This occurs regardless if correct or incorrect password is set.

Scenario 2: Admin chooses to use a different user to give setup access, like config@domain.com.

Setup page shows no errors. However log shows the following error:

| 2016/06/27 15:48:30 | 2016-06-27 15:48:30.430 [pool-9-thread-4]  DummyServletRequest.getUserPrincipal()  SEVERE: null
| 2016/06/27 15:48:30 | tigase.db.UserNotFoundException: User does not exist: config@domain.com, in database: jdbc:derby:tigasedb;create=true
| 2016/06/27 15:48:30 | 	at tigase.db.jdbc.TigaseCustomAuth.userLoginAuth(TigaseCustomAuth.java:970)
| 2016/06/27 15:48:30 | 	at tigase.db.jdbc.TigaseCustomAuth.plainAuth(TigaseCustomAuth.java:653)
| 2016/06/27 15:48:30 | 	at tigase.db.AuthRepositoryMDImpl.plainAuth(AuthRepositoryMDImpl.java:194)
| 2016/06/27 15:48:30 | 	at tigase.http.setup.SetupModule$1.checkCredentials(SetupModule.java:105)
| 2016/06/27 15:48:30 | 	at tigase.http.java.DummyServletRequest.getUserPrincipal(DummyServletRequest.java:400)
| 2016/06/27 15:48:30 | 	at tigase.http.java.DummyServletRequest.isUserInRole(DummyServletRequest.java:378)
| 2016/06/27 15:48:30 | 	at tigase.http.setup.SetupServlet.processRequest(SetupServlet.groovy:77)
| 2016/06/27 15:48:30 | 	at tigase.http.setup.SetupServlet.service(SetupServlet.groovy:66)
| 2016/06/27 15:48:30 | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
| 2016/06/27 15:48:30 | 	at tigase.http.java.RequestHandler.handle(RequestHandler.java:96)
| 2016/06/27 15:48:30 | 	at com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
| 2016/06/27 15:48:30 | 	at sun.net.httpserver.AuthFilter.doFilter(Unknown Source)
| 2016/06/27 15:48:30 | 	at com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
| 2016/06/27 15:48:30 | 	at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(Unknown Source)
| 2016/06/27 15:48:30 | 	at com.sun.net.httpserver.Filter$Chain.doFilter(Unknown Source)
| 2016/06/27 15:48:30 | 	at sun.net.httpserver.ServerImpl$Exchange.run(Unknown Source)
| 2016/06/27 15:48:30 | 	at tigase.http.java.JavaStandaloneHttpServer$ExecutorWithTimeout$1.run(JavaStandaloneHttpServer.java:192)
| 2016/06/27 15:48:30 | 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
| 2016/06/27 15:48:30 | 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
| 2016/06/27 15:48:30 | 	at java.lang.Thread.run(Unknown Source)

Oddly even with this error, I can still connect using those credentials, and the user is in fact made.

Scenario 3: init.properties is set to use a different user not in datbase

http/setup/admin-credentials=config2@domain.com:config

This scenario works just fine with or without database setup.

It works, but seems a bit messy since the logs get jammed up a tad.

Also, this one is for you and %kobit Do we want to highlight/mention the init.properties property at all?

Andrzej Wójcik (Tigase) commented 8 years ago

As for scenarios 1 and 2:

This is same exception. I lowered log level of this exception from SEVERE to FINEST as it is properly handled. So there will be no entries like that.

In case of usage user/admin credentials from database then user in database should already exist and to login you need to pass user bare jid - not just username as username.

In scenario 2 you stated:

and the user is in fact made

So user which was added to admins list was not in database before? If so how it was created? It should not be created.

You also stated:

It works, but seems a bit messy since the logs get jammed up a tad.

How log is jammed? with this exceptions reported above? If so, this will be fixed in next snapshot build.

%daniel If for scenario 1 and 2 there will be any additional things to fix, please provide me with step by step, ie. I added user as admin by adding it to list of admins in setup page. As right now I'm not sure how you did few things, but I'm sure my current changes will fix issues reported (at least some of them)

Daniel Wisnewski commented 8 years ago

%andrzej.wojcik it looks like I had some of the intentions wrong, let me clarify. I had guessed (without reading) that the setup page access screen would provide for the creation of a new JID on the server. As you said this is incorrect.

The errors are cleaned up, so that looks good.

Is the setup access page intended to edit the init.properties file and add http/setup/admin-credentials=user:pass? If that is the case, the default username and password is removed, but the line is not added back with appropriate or any credentials.

init.properties after setup shows following:

config-type=--gen-config-def

--virt-hosts=test.net
--admins=admin@test.net


--debug=server

--user-db-uri=jdbc:derby:tigasedb;create=true



--sm-plugins=+jabber\:iq\:auth,+urn\:ietf\:params\:xml\:ns\:xmpp-sasl,+urn\:ietf\:params\:xml\:ns\:xmpp-bind,+urn\:ietf\:params\:xml\:ns\:xmpp-session,+jabber\:iq\:register,+jabber\:iq\:roster,+presence-state,+presence-subscription,+basic-filter,+domain-filter,+jabber\:iq\:privacy,+jabber\:iq\:version,+http\://jabber.org/protocol/stats,+starttls,-msgoffline,+vcard-temp,+http\://jabber.org/protocol/commands,+jabber\:iq\:private,+urn\:xmpp\:ping,+pep,+zlib,+message-archive-xep-0136,+amp

--comp-name-1=muc
--comp-class-1=tigase.muc.MUCComponent

--comp-name-2=pubsub
--comp-class-2=tigase.pubsub.PubSubComponent

--comp-name-3=http
--comp-class-3=tigase.http.HttpMessageReceiver

Andrzej Wójcik (Tigase) commented 8 years ago

I think none of setup pages was intended to modify content of file directly, however modification on last page should work.

This line should be added when you fill credentials with non empty and non default values in one of last steps (@Setup security@ if memory serves me right). In other cases line will be removed.

Daniel Wisnewski commented 8 years ago

The line is only removed, nothing is added regardless of what I put in the Setup Security Page.

Andrzej Wójcik (Tigase) commented 8 years ago

Ok, finally I've found cause of this issue.

As I tested I had this line in my init.properties file with non-default values and in this case data was properly stored. However when I removed this line I simulated your case in which credentials where not added to init.properties file.

Found cause of this issue and fixed it. Fix will be part of next snapshot build.

Daniel Wisnewski commented 8 years ago

functions as intended. Closing issue.

Type	Task
Priority	Major
Assignee	Daniel Wisnewski
RedmineID	4272

#9 Closed

Implement web installer module

Issue Votes (0)

Watchers (0)

Reference

tigase/_server/tigase-http-api#29