I have an Internet facing Domino server in our DMZ on which customers log support requests, the customer is required to authenticate, ie. anonymous access is not available. I have developed internal 'wallboards & dashboards' for our support staff, which need to be displayed using web browsers. To allow the wallboard/dashboard web pages to open without authentication I point them at a replica of the database on the second 'internal' server, I do not force a 'consistent access control list' between the replicas and allow Anonymous access to this replica. My problem being that replication across the servers is every 20 mins, so the wallboards are up to 20 minutes behind. I cannot point my wallboard 'Computed Fields' etc at the 'live' database in the DMZ as it throws an error presumably because there is no authentication.
Typical error:
Error while executing JavaScript computed expression
Script interpreter error, line=1, col=57: 'db.getView().getAllEntries()' is null
JavaScript code
1: return db.getView("$FaultStatsDayOpen").getAllEntries().getCount().toFixed();
I imagine I have some of the concepts wrong of how to achieve this. But basically I need XPages from the internal server to be able to retrieve data from views and documents on the DMZ server even though it does not allow Anonymous access.
I can't seem to find this on any of the forums, so any help would be appreciated.
sessionAsSigner allows the code to access databases on any servers in the same domain using the access of the ID signing the XPage. Remember that all design elements included in the XPage need to be signed by the same ID.
If the server is in another domain, you'll need to replicate the database across a server in the same domain in order to access it.
Related
In my couchapp two databases are being used
1 Is for application data
2 Is "_users" database.
In my application In one form I'm trying to implement autocomplete where data source is a "view" created in "_users" database.
Now when I login with normal user id other than admin. While trying to access the view inside "_users" database I'm getting the error 403 which is :
{"error":"forbidden","reason":"Only admins can access design document actions for system databases."}
Is it possible for me to allow and limit the access for non admin users to that view only ? So I can get the list of users from _users database into my application.
I've never been able to do many tasks that require much custom with CouchDB by itself. I've always needed a script somewhere else that gives me the info that I need.
What works for me is this setup:
A gatekeeper Sinatra app that has admin access to my CouchDB
Using CouchDB's config to proxy to my Sinatra app. httpd_global_handlers _my_service {couch_httpd_proxy, handle_proxy_req, <<"http://127.0.0.1:9999">>}
The reason for the proxy is because any request that comes through to your gatekeeper will have the AuthSession token set. Inside your gatekeeper, you can GET localhost:5984/_session passing the AuthSession cookie along, it will tell you who is making the request, allowing you to look them up and see if they have access, or just give everyone access to whatever you like. Another reason for the proxy is to avoid any CORS nonsense since you're making the request to yourserver:5984/_my_service.
Update
A purely client-side/javascript solution means that it will be fundamentally insecure at some point, since well, everything is on the client-side. But perhaps your application, doesn't need to be that secure. That's up to you.
One workaround could be to make your application authenticate as a predefined admin, and then create more admin users that way. You could authenticate once when your application boots or on an as needed basis.
The "problem" is that CouchDB sees the _users database as fundamentally special, and doesn't give you the opportunity to change the credential requirements like other databases. Normally you would be able to use the _security document to give role based or user based access. But that's not possible with _users.
An alternative implementation might be to keep track of your own users and forgo the _users database altogether. In that case you could set your own cookies and have your own login and logout methods that don't depend on CouchDB's authentication scheme. You could query your own _view/users because it would be in your main database. Things wouldn't be locked down tight but they would work fine as long as no one was interested in hacking your system. :)
There is an application that we are using it both on XPiNC and browsers.
Before you can access the application, you must log-in with your user.id from lotus notes. The problem is there are several login msgboxes ( where you must again log in with your username and passwords ) saying:
The server says /xsp/.ibmxspres/dojoroot-1.8.1/dojo.
or
The server says /xsp/.ibmxspres/.mini/dojo/.en-us.
or
The server says /xsp/.ibmxspres/.mini/css.
or
The server says /xsp/.ibmxspres/.extlib/icons.
and so on. Even when I just hit F5 when I'm logged on in application ( there is, also, a computed field which displays the username ) those type of messages are being displayed.
What should I do as a developer? Or there must be some settings at the server?
I have the following ACL rights:
ACL: User type: Person and Access: Manager.
Effective access: all the checkboxes are checked except Full Access Administrator
Thanks for your time!
Ok, this should be straight out of the box ;-)
What I find strange is that the ressources you seem to be asked for access to use are some of the "built in" ressources (Dojo, css, etc.) in XPages...???
So first thing is really to test that this has nothing to do with your application:
Create a new application
Set a proper ACL that will force you to log in (Default reader or higher, a person called "Anonymous" no access)
Create a simple XPage and open it from the browser
What happens?
If everything works, then you need to add some elements that use the ressources (css, Dojo, etc.). Then what happens?
I guess you will see the same problems... If so, you need to have a look at the way you have set up your server for web access. Are you using internet sites? Do you use basic or session based authentication?
What does the ACL of your application look like?
What you experience could be caused by "realms" i.e. the "path" to which you log in. A simple example:
If you are required to log in to access the ressource /path/db.nsf/view/doc1?openDocument then your realm will be "/path/db.nsf/view/" - if then you try to create a document using /path/db.nsf/newDoc.xsp then you could be asked for access to the realm "/path/db.nsf/".
I must admit that I haven't seen these issues for quite a while - but that may be due to the fact that I control access to the database as a whole - if users need access to something inside the database I implement it using "public access". But first, let us hear a little more about your findings before we chase it as a realm issue ;-)
EDIT:
Ok, so you are using basic authentication. There are lots of good reasons to use session based authentication instead. However, that does not explain your problem. What OS are you using? An OS with file access in the file structure? Could it be that the user running Domino does not have access to the ressources? Have any (file) restrictions to these directories been set up? You really should not be prompted to login for these ressources....
Did you try another "new" application?
/John
Switch to session based authentication. The multiple prompts point to BASIC where you can't logout unless you close the browser
I am using an xPage as an iWidget in IBM Connections 3.0.1. I have extended the ajax proxy to point to the nsf. During testing everything was working correctly but I realized it was only working when I was already authenticated with the application (I do use SPENEGO to auth). When I load connections in a fresh browser session I get the BMWIW0001E:Unable to load iWidget error. But if I load the app then reload connections all is well.
Is there a way to pass through the user's credentials or otherwise prompt for a login?
Is there a way to hide the "BMWIW0001E:Unable to load iWidget " error and display a custom error page?
The error message is generated afaik by connections, so you might be better of asking on Server fault or the IBM Connections forum.
For authentication in a mixed environment you have to sort out the trust relationship between the servers. Pick your poison: LTPA, oAuth, not sure about spinego.
As a short term remedy you could use a landing xpage in your widget flagged for anonymous access (allow public access and in the ACL: anonymous with no access but read public access.
In that page you check #UserName and redirect to a mini login or the real widget page. Redirect can be also by loading a dynamic control
CouchDB access as a rest service seems insecure. Anyone can hit the database and delete/add documents once it is exposed.
What strategies are there to secure the CouchDB?
A lot has changed since 2009, so I'm going to throw an answer in here. This answer is drawn from this page on the wiki.
CouchDB has a _users database that serves the purpose of defining users. Here's the gist straight from the wiki:
An anonymous user can only create a new document.
An authenticated user can only update their own document.
A server or database admin can access and update all documents.
Only server or database admins can create design documents and access views and _all_docs and _changes.
Then, for any given database you can define permissions by name or by role. The way authentication is implemented is through a _session Database. Sending a valid username and password to the _session DB returns an authentication cookie. This is one of several option for CouchDB Authentication. There're a few more options:
This option is a little old 1.0 was a few months back, we're on 1.2 as of today. But it's still very well outlined.
And this one from "The Definitive Guide"
Also, depending on which hosting service you might be using, you'll have the option to restrict access to couch over SSL.
Between Node, Couch, and a variety of other technologies that effectively scale horizontally (adding more servers) there's an interesting kind of pressure or incentive being put on developers to make applications that scale well in that manner. But that's a separate issue all together.
The only thing which really works currently security wise is something like this in your CouchDB configuration.
[couch_httpd_auth]
require_valid_user=true
[admins]
admin = sekrit
This puts basic HTTP auth on all of CouchDB. Even this is not well supportet in client libraries. For python e.g. you need a patched library.
The second approach is to put a proxy in front of CouchDB and let the proxy do the authentication and authorization work. Due to CouchDB's RESTful design this is quite easy.
All other approaches must be considered up to now highly experimental.
This may be a little different from your original question. If your couchdb is only a back-end store for a full server app, you can make a special account for the server app to use and require those credentials for access to couchdb.
On the other hand, a pure couch app that people hit directly through a javascript client needs a lot of care to be secure.
Using rewrites is not optional. You need a vhosts config that forces requests to your domain through your rewrites.
Rewrite routes */_all_docs and /*/_design/* to a 404 page. Otherwise users can list every document or get your whole app.
Rewrite generic object access, ie /dbname/:id to a show that can deny access if the user is not allowed to see the document. Unfortunately there is no equivalent workaround for doc-based access control of attachments.
We used haproxy to filter GET requests on _users. There is no legit reason for someone from outside to get a user record or list all your users. We want users to be able to register so we need write access. Currently couch cannot block read access to a db and simultaneously allow writes. It's a bug. Filtering with something like haproxy is our best workaround for now.
Use your own database to keep contact information that is in addition to what is provided by _users. This allows more control over access.
validate_doc_update should carefully reject any writes that should not be allowed.
In every case you need to imagine what someone who understood the system could do to subvert it and lock down those avenues of attack.
CouchDB does cookies, SSL, oauth, and multi-users just fine:
Here's some actual code in python:
from couchdb import Server
s = Server("https://user:password#example.com:6984")
Request the cookie: url encoded above and below, of course
You have to put the credentials twice to get started with the first cookie
Both in the Server() constructor as well as the _session POST body
code, message, obj = s.resource.post('_session',headers={'Content-Type' : 'application/x-www-form-urlencoded'}, body="name=user&password=password")
assert(code == 200)
Now you have received a cookie, extract it
cookie = message["Set-Cookie"].split(";", 1)[0].strip()
Now, exit python and restart
Next, Request a server object, but without the username and password this time
s = Server("https://example.com:6984")
s.resource.headers["Cookie"] = cookie
Yay, no password, try to access the database:
db = s["database"]
Optionally set the "persistent" cookie option on the server side to make the cookie last longer.
Have you read CouchDB documentation http://couchdb.apache.org/docs/overview.html? It has a "Security and Validation" section that addresses some of your concerns.
I have an scheduled agent that is trying to access a database on another server. When it runs I get an error 4063 - Database ...databasename... has not been opened yet.
The servers is listed in the ACL as manager.
What are some other possible causes for this errors?
Does the other server trust the server executing the agent? Check the server document -> Security -> Trusted servers.
It's possible to get a handle to a database without opening it. If you try and call most methods without opening it first then you will get that error. The most likely explanation though is that you don't have access to open it.
What id signed the agent? Probably not the server. The agent will run with the authority of the agent signer, so that is the id that needs to be in the ACL of the database you are trying to open.
There are a whole bunch of rules about how agents can run under different authorities and on behalf of different users. That can get pretty complex if the situation requires it. But check the agent signer has rights to open the database first then look at any "run on behalf of" settings.
Check the server document of the server, where the database resides. In the Access server section does the Trusted servers field contains the name of the server, where the agent runs?
One tip: print out beforehand db.Server and db.Filepath to see what exactly you are trying to open.