XCC authentication already does digest authentication with whatever username and password you supply. That's pretty secure, and SSL/TLS helps too. But it sounds like you want to treat those credentials as a soft target, and instead authorize each update as needed?
If I understand the use-case correctly, that sounds like a reasonable solution. I'd want to use SSL/TLS for both requests as well. I'm sure you already know that xdmp:random() with no parameters generates a 64-bit unsignedLong, which gives you a pretty large token space. I'd use a directory prefix for the token documents, for convenience and to reduce the attack surface a little. When you check for a token document use exists(doc($uri)). Don't use xdmp:exists, because it won't take a read lock and this is a case where you want that lock. You probably don't need to call xdmp:lock-for-update, because lock contention should be vanishingly rare. -- Mike On 18 Aug 2014, at 15:16 , Will Thompson <[email protected]> wrote: > A Java application will somehow need to securely be allowed to insert > documents into the dbs of its callers, which are all other ML databases > (several developers, QA, and production). ML executes http-get calls to Java > with parameters for the jobs, Java does a bunch of work (this takes a while), > and then finally inserts documents into the caller's db via XCC. > > I have used semi-secure but convenient solutions for purely internal > applications; however, this one will have to work over the Internet. My first > thought was to have the caller generate a token, pass to Java SSL endpoint > along with other parameters, Java calls XCC with limited credentials and the > token, token is checked by caller and insertion is amped if it matches, then > token is deleted. Will that suffice, or are there better, smarter ways to > accomplish this? > > Thanks, > > Will > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
