I am attemtpting to use SessionAsSigner.getDatabase in SSJS to access a db on a different server. But it always returns null. For example I use:
var db = sessionAsSigner.getDatabase("canonical name of server","log.nsf", false);
There is probably error in server security setting. You can read this page: http://www-01.ibm.com/support/docview.wss?uid=swg21086111
When you use sessionAsSigner the server you are connecting to is able to authenticate who you are when you log in.
When you are running code on the server (A) and you need to talk to another server (B), then the first server has authenticate with A credentials. It cannot authenticate as you.
To allow it to run correctly you need to set up server A as a trusted server on server B.
You can set trusted servers in your server document.
You can programatically check if this is set using the NotesSession.isTrustedSession() method.
The problem is that you code is signed with different signers.
Try to resign the database with your or the servers id.
That will probably fix your problem.
The Server you are using needs to have access and a connection document to the server you want to access. So The first thing to do is: check If your server is listed in the "Who can Access this Server" Field in the Server document. Then check the Trusted Servers Section. Then check the ACL of your log (your executing server and the XPage signer need to have access to log.nsf)
Related
Very strange issue I am facing from past few days. I am just able to login to any application on my domino server using "Mozilla Firefox". If I use any other browser (Chrome, IE), it just stays on the login page with absolutely no information, everytime I login in it again shows back the login page with no error message at all. Its quite strange since its working perfectly fine on Firefox.
I am not sure, but I somehow feel that it has something to do with the configuration. Would really appreciate if someone can guide me here.
Edit 2:
Selecting Single Server, does work, that was the simplest solution; as of now we do not need "Multiple Server".
However, we do not use any other "Internet Sites", I tried to remove the organization field, however, that lead me to "An R5 web SSO configuration already exists", which in turn lead me to here. However, I am able to move further here with "Multiple Servers".
Edit 1: Based on the answers, here are the things I tried. Please find below the snapshot of each of it for better understanding..
LTPA Token Configuration
Server Configuration for LTPA Token
Network tab - before login
Network tab - after login
Console shows nothing before or after login, neither does the server log files. Also, I am able to access the names.nsf database with absolutely no problem. Lastly, I try to access a database with no anonymous access and hence get redirected to the login page (however, as question mentions, it just stays in loop)
Ok, you may need to provide a little more information.
Are you doing a "normal" login using domcfg and a "...&login" url? Or are you trying to open a design element in a database that has no access to "anonymous" and thus redirects to the login?
You can easily check that "standard" login by opening the url: http://yourserver.com/names.nsf?login. Does it behave differently in the browsers? If not then your server setup etc. is Ok. Then you have to look at the solution that tries to log you in.
Your first place to check is in the browser's console. Are there any errors in there? E.g. some client side Javascript that stops running? Check the network tab when you inspect the console/developer tools. Does it send the right requests?
Another step is to check the console/log files on the server. If you have grown your own solution then you may want to add some simple print statements to prove that it sends what you think.
Finally, you can use a network sniffer (like wireshark) to see exactly what is sent between your browser and the server.
/John
A login- page that reloads itself after every login without a message like "Wrong username or password" or similar normally happens if the session authentication for the server is configured as Multiple Servers (SSO) (Found in Server document on Internet protocols-Domino Web Server, if Internet Sites are Disabled or in Internet Site document, if they are enabled).
In that case an LTPAToken has to be configured as well, and this token has to have a configured domain name. Whenever you try to access a server with SSO enabled using a hostname without domain or with a different domain, then exactly this will happen: Login- Page reappears after every try to login.
Example:
if the servername is myserver with ip 10.10.10.1 and the LTPAToken is configured for ".mydomain.com", then the only valid URL for login is:
hxxp://myserver.mydomain.com
Trying hxxp://myserver or hxxp://10.10.10.1 will result in exactly the described behaviour.
It is important to know, where to look for the "right" SSO- Configuration document.
If the server is configured to use "Internet Site documents" (Server- document, Basics- Tab, Load Internet configurations from Server\Internet Sites documents enabled) , then the SSO- document needs the field "Organization" to be filled. In that case you will find it in the Web\Internet Sites- View of the domino directory.
If Internet Sites are disabled, then the Field "Organization" has to be empty. In that case you find the SSO- document in the Web\Configurations view.
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.
In Jdeveloper, what happen if I remove cwallet.sso? what is this for?
I read that it stores security credentials, but I removed it and my secure pages still asked me to login and I was able to log in using the users that I have in jazn-data.xml and the users that I have in my weblogic server.
It's not used for that, and if you are defining the database connection on weblogic server you should not need it, but in development time when you define database connection, or any connection that has password for that matter the cwallet.sso is the one that save and hash this password so that when you copy the project to another person it still works fine.
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.