Adding a Remember Me Feature to Domino for Automatic Login
Every now and then I get asked about adding a "remember me" feature to a Domino login page so that the user doesn't need to remember/enter their name/password each time. Each time I explain that it's not possible with Domino and, even if it were, it's not advisable.
On occasion I'll go on to to suggest that most current browsers give the user the option to remember the form details anyway. Normally this suffices.
Now though I have a user who really wants this feature, whatever the cost (in terms of actual cost to implement and in terms of lost security). I need to advise just what the cost is on both sides of the coin.
The question is -- is this even possible?
Having spent some time thinking about it I've got a few ideas floating about in my head. Whether they'd work or not I don't know until I've tried them out. What I need to do is find which would be the least insecure.
What I wondered was if anybody else had tackled this already? If so, how?
Skip to the 
You can subscribe to an individual
NCT Remember me can do this afaik
http://www.thenorth.com/ncthome.nsf/html/rememberme
I don't use it so can't say anything about it.
I have been researching this also. If your ultimate goal is to avoid having users login, You can use a .dll configured as a DSAPI filter to hook the users windows account. see secdom.dll here
http://www.nsftools.com/tools/apisamples.htm
As Henning says, Andrew does it with NCT rembember me.
PistolStar has a product that does this as well.
http://www.pistolstar.com/
Hi Henning.
I saw that page while Googling and was curious how it worked. At first I assumed they'd written something in DSAPI but then noticed it says "Does not require a DSAPI filter" and it only talks about using JavaScript. This gives me an idea how it works and it's not really what I'm looking for. Ideally I'd like a non-JavaScript solution. Where the cookie is set by the server (assuming "remember me" is ticked).
Does anybody know if Domino's session authentication method is available as a DLL call from LotusScript?
Jake
Thanks Curt. Will look in to them now.
Hi Jake
AFAIK with @sethttpHeader you could write cookies.
After login you write with @SetHTTPHeader the cookie. And while opening the loginform, test the cookie with @GetHTTPHeader.
Hi Urs,
But that would involve storing the user's password in plain text in a cookie would it not?
Jake
I've set up "Urs" method (or a look like) in domBulletin years ago.
And yes, the cookie was storing the user password in clear text. Plan was to encrypt it in a later domB version that's not there (yet).
But anyway, is it that usefull to store the cookie encrypted ? if a user can access your PC, the remember me method will be valid for him too. If a user "steal" your cookie, it will still work because he has stolen the encrypted one. Encrypting the cookie prevents the user from knowing your password...but as you know if your app login form is not HTTPS, your password is sent in clear text to the server...
I guess it's just a matter of evaluating the risk and accepting a certain - be it very small - degree of uncertainty based on the requirement of the application...
Hello,
On intranet you could create some lotus notes document likes token on the first login. Your keys can be an IP Address, CGI variables , but be carreful with security :) ...
I think single sign on or some certificate could be used, but I'm not a master about SSL protocols, certficates and other thinks like this ...
Have a good day an Plz forgive my english.
Hi
I had a customer which viewed contacts from a CRM solution on their BlackBerry browser. We did not want the users to time out and have to login again, so a work around was needed.
By storing username and password encrypted in cookies and some code in a java agent the user would only have to log in the first time.
From then on the user would automatically be logged in when opening the contacts webapp.
Like you I don't recommend doing this,
... but sometimes you have to weigh security against convenience and the level of confidentiality.
Jesper Kiaer
/Jezzper Consulting
http://nevermind.dk
Jake,
Just come across this - http://blogs.nil.com/jeds/2009/04/04/ltpa-token/
Looks like it might be useful.
Hey Jake,
There is an API call you can make from Lotusscript, and I'm in the process of implementing it right now. It came from NCT, and it is the solution we're pushing most of our customers towards.
http://www.thenorth.com/ncthome.nsf/html/nctsso
Thanks to everbody who has responded since I last did. Some very helpful links/ideas in there.
If I get anywhere with this and have a eureka moment. You'll be the first to know.
Jake,
if this is within a corporate network, and Domino is installed on a windows server, you can use the iisWASPlugin for single sign on to pass credentials to Notes. I've set this up on multiple domino servers version 6.5 - 8.0.1. Basically its an ISAPI Filter running in IIS that forwards your windows credentials to the domino server, so in turn you need to have their Network accounts added to the Domino directory. For instance domain\username. This only works for Internet explorer, however, if you turn on NTLM for firefox, it works there as well.
Basically any time I want to access any notes resource with single sign on, I access the URL on port 8081 and that facilitates the single sign on for me.
As far as the Remember Me option, I have also modified the forms database that maintains the login page and modified the attribute to allow remembrance. This was awhile ago, and I don't remember what the attribute is called, but basically there is an attribute on the text box which prevents the browser from storing that information. Changing that attribute allows the browser to do the inherent "remember me"
I use the dombulletin remember me approach, and added a javascript hashing routine (rot13) to hash the username and password. The advantage of this is that if you inspect the cookies you cant see/ dont understand the username & password. The same javascript routine looks for the cookie when you hit a page, unhashes them and submits them on the embedded log in form, bringing the user back to the same page in the blink of an eye (almost not noticeable), logged in.
The disadvantage is that its not totally secure as you can use the same javascript function to reverse the hashing, if you are so dastardly...
I wonder could you use a webqueryopen to pick up the cookie value, unhash it server-side so the browser cant see a hash key on the client side, and deliver the the values back to the log in form. Or an onLoad ajax call... I think you could.
I wouldn´t spend to much time in this.
IBM said on the Lotusphere 2009 that they are plaing to implement a SPNEGO Authentification in Lotus Domino 8.5.x (rumors on the lotusphere 2009 say it will be included in 8.5.1, and that will maybe released in the end of 2009).
See this slide here:
http://www.slideshare.net/edbrill/lotusphere-200-inv102-lotus-notes-and-domino-strategy-2009-presentation
Another idea would be a 3rd Party tool like the one from pistolstar:
http://www.pistolstar.com/password-plugin-products/password-power-8.html
Hi Jake,
This is crude and simple, but my punters like it for intranets.
I auto generate and email an individual URL for them to bookmark with &u=&p= arguments at the end, then I changed the custom login form to have qsexploded, Arg Names, Arg Values, then the default value for Username is @If(ArgValues="";"";ArgValues[1]) and Password @If(ArgValues="";"";ArgValues[2]).
Then they just press login.
Works for me (on a basic level) anyway.
P.S....Isn't this exactly what you did @ the old Prominc support portal? - Pity their new me thingy doesn't do this.
Shhh. Don't tell everyone Nick ;o)
I can't remember exactly, but I'm pretty sure it wasn't me who did that part of the Admin portal. Personally, I wouldn't use the password on end of URL method. Just seems wrong somehow.
My idea is the almost the same as Col.
I store the username/password in a cookie (rot13) and when a user tries to login this cookie is evaluated via an notes agent. (HTTP_Cookie)
Within this agent i check the password with session.VerifyPassword(PW1, PW2)
If the outcome of the verify is true i logged in via names.nsf...
ie
Print "[" & szWebDB & "/names.nsf?login&username=" & szU & "&password=" & szP & "&redirectto=" & szWebDB & "/main?Open]"
Sorry, someone pointed me to this today so I thought I'd answer:
NCT Remember Me uses a dll on the server, but not DSAPI. The danger with DSAPI is that its ALWAYS running for every single web transaction. Any problem can be a real big deal.
The remember me product comes with teh dll and a license key you drop on the server, and a notes database template that implements the function. A script is referenced from the page where the remember me checkbox lives. The script actually generates the checkbox and implements the functionality, including any cookies that are needed. The script itself is generated dynamically by the database that implements remember me.
In the most basic installation, you can add "remember me" to a web page by copying a very short block of html onto the page and then you're done. The html calls the script, puts the checkbox on the page (ready for css to modify) and handles all the functionalty.
For more advanced uses, there are documented calls so you can do it yourself.
I may do a dsapi verson later, but I REALLY don't like DSAPI. I've seen so many servers crash from people's mistakes in DSAPI that I try to avoid it at all times.
What my next plan for Remember Me is, would be create a drop in replacement for the Domino Session based login form that implements it site-wide in one step. You could do that now if you used the advanced documentation to build it yourself, but I think it should come with the tool.
For those of you using stored usernames and passwords (and shame on you for it) -- you should encrypt the cookie on the user side not just rot13 it. Even better, store it on your side in a profile document and reference it with a hash key that you store in the cookie. When they hit your site, use the key to get the information, and use a back end ajax call to do the login. The login response will contain the ltap_token cookie and you'll have logged them in.
Having just ahd a play, I can confirm the ltpa cookie works as linked by Mark Barton (http://blogs.nil.com/jeds/2009/04/04/ltpa-token/).
Took me about half an hour with very rusty Java skills to create an agent that authenticates me with no password and redirects me to my mailbox.
Obviously you'd want something at the front end to send username and a key of some sort to ensure not just anyone could log in with the target account, but it does work.
Plus sides, no password in the cookie (actually, no password needed at all), and no plugins (would work on a linux server as well).
...and that took me to an even better idea - once someone has logged in, why not just keep the cookie they've been given for longer. No need to create one from scratch.
I created an agent that does the following:
Get the DocumentContext
find http_cookie, and strip ltpaToken cookie value out
Re-set it using print headers so it lasts until 2030 (or however long you want it to last).
redirect!
You could probably just add this agent in an img tag on any page after the user has logged in, and have it redirect them to the image after it has finished.
It doesn't look like subsequent calls to the domino server reset the expiry time, so this might be an easy answer - one login, lasts for days/months/years
@Tom -- Very nicely done by Mark Barton. Someone with the right skills could use that information to create a solution every bit as good as NCT Remember Me. It makes a nice alternative to the API calls I used in creating mine. What I like best is that it is entirely cross platform.
Bear in mind that just creating the token doesn't solve all the issues of page refreshing, cookie management logging and debugging -- but presumably if you've got the chops to use that tech note you could spend the time to solve those problems just as I did.
3rd comment, perhaps I should slow down.
The 2nd idea won't work as the cookie expires after the normal 30 mins because the time is encoded in the cookie itself. If I'd thought about the nil.com article , I'd have remembered that.
I'll try a combination of the two (normal login, replace the token with a freshly generated, UHT version), assuming the server doesn't complain after 30 mins of inactivity...
Don't worry about the number of comments Tom. It's nice to see some thought being provoked.
@Tom --
The cookie itself is cleverly built to resist tampering. The Expiration and Username are built into the token and validated with the sha1-hash of their values, which is itself salted with the secret key.
Even if you KNOW the salt (the secret key) from the server and you re-generate the token using the expiration time and creation time, if you make them too far apart they won't match the key duration on the server. When the server generates a matching hash with the same information (checked against its own maximum duration) this would be spotted.
* Of course, nothing says they had to IMPLEMENT that safety check, but they certainly could and should have.
It's true that the server could reject it if it's older than the default key duration, but it doesn't seem to care (at least, my cookie is over an hour old now with no access to the server, and it's just let me back on). I'll try it again after Easter and let you know if it works. It's still showing me as a valid user on the admin console as well, which is a good sign.
I now have an agent that you run after you've logged in normally (though this is just how I assume people would want it to run if they're looking for a 'remember me' type function, it could work without the std Domino login as long as you can pass it a username).
It examines the existing cookie, grabs the username out of it and sets a new cookie for that user lasting 6 months. Obviously you could have this code called in a frequently used page (image/css tag?) and keep this cookie 6 months out.
@Tom -- that's all well and great. Can you tell me what happens if the http task is shut down and restarted, or if the sso configuration changes between when a user comes to the site when they come back?
I had to handle the kinds of things you did in a different way, making sure to handle those situations. Essentially, if you come back to the site and have a valid NCT Remember ME cookie, and had set the flag to "yes" remember you, the code generates a new token for you which will be valid even if the http task is restarted or the sso ltpa token configuration is changed.
In any case, @Tom (and by proxy @Mark Barton) the use of that Java call to build your own LTPAToken is absolutely every bit as valid as the way NCTRM does it with a couple of API calls.
As I said earlier - there's nothing here that would prevent someone from rolling their own really good solution, other than time and a bit of skill.
The hard part isn't really making the token, so much as making the token safely and not putting code out there that can be called by other code, which will make tokens for just anyone's name you pick.
That, and wrapping the token creation process is a solid, documented, easy to deploy and roll out package with all the cookie handling and page reloads and so on.
Like everything we do as consultants, developers, and ISV's -- its all just code. There's no magic in there. My philosophy with NCT Search was the same as with NCT Remember Me.
Do a really solid job and make reliable code that people can roll out safely, then sell it cheap enough that its not worth them doing it themselves or hiring it out to be done by an expert.
I love that model. The truth is, Remember Me doesn't sell all that well. Its probably priced too high, but I don't think so. Its a subset of functionality from a more advanced product called NCT SSO, which is designed to facilitate cross system shared logins when you don't control the other side. Even there, the real value isn't the little API call. The real value is the token passing schema with examples and utilities and documentation to make it easy to roll out. NCT Search has even less magic in it than the SSO products do -- its just well tailored to a very specific need, and for what it does, its cheap.
I think its fantastic that this code is out here and people who want to can roll their own. I just hope people do it carefully and consider the side effects when they do.
@Andrew: I agree with you 100%. If I decide I need that feature I'll be buying it, not building it myself.
The sites I create and host that require login could benefit from it, but I don't think not having it has been any deterrent to users. If that changes I'd pay your price in heartbeat.
I've bookmarked your web site for future reference.
Peace,
Rob:-]
I don't use Notes for anything other than an admin tool/blog/email client these days. However, for my blog (courtesy of Jake) I use https with a browser certificate (exported from my Notes id) to access the databases over the web.
I think that this is the right way to have "remember me" working. It's up to the user to decide if they want their browser to prompt them with a password when accessing the certificate. It seems to me that a huge part of the security infrastructure that is built into http goes mostly unused.
As far as I remember, the pain of the whole thing was getting the certificate imported into the browser.
@Bernard - It would be great if browser certificates became the common method. The problem with it is that for a wide range of users, its very difficult to support. You setting it up for yourself to access your data is one thing. Having a large set of "customers" or "site users" with wide ranging skills and browser configurations to support is -- at least so far -- untenable.
Andrew - I'm not trying to put down the work you've put into your solution, just looking to see what I can do with an interesting problem. There's almost always someone who's been there before me, done it better and produced a solution you can buy, but where's the fun in that?
If you shut the server down it seems fine (at least the http task, can't shut the whole server down right now). Change the secret in the SSO configuration and the cookie becomes invalid (though when that happens automatically, I don't know). I've never changed a pre-existing sso configuration though and not shut down my public domino server for at least a year, so that's not something I'm going to worry about.
To be honest, this isn't a problem I need an answer to right now, and certainly not one I need to be able to make money out of, it's just something that caught my interest.
Back to my results - the long term cookie was still operational after the long weekend, so I'm going to stop at that point - it's good enough to satisfy my curiosity.