Siteminder login, forceUser, forcePassword, credential search assist

[gregm]

3 items below;

1. My instituional network recently changed from the usual outlook/exchange or whatever the heck it is login to a siteminder based single sign on, which broke the Davmail login. I worked my way through the siteminder javascript & associated brain damage and got davmail working again (nice!). I think handling the new type of login could plausibly be fit into the ExchangeSession and ClientFacade session startup code. Since its its a lot different from the usual form login (webpage and javascript scrapeing is needed to work out the post parameters and redirects) it seems like something special purpose is needed. I expect the front-end of the SSO business to be highly idiosyncratic even though once authentication is done Siteminder just drops a big SMSESSION cookie and goes away.

2. I added "forceUser" and "forcePassword" davmail.properties to override credentials received via caldav, and a shell script exec() to allow the user to supply a credential search algorithm at login-time. Its a big help for me because I have lots of devices w/ calendars and when my institutional credentials change I have to type all that junk into each one- this way I only need to manage it at the davmail node.

3. Part of the SSO change on my institutional network involved a bunch of cert changes that made davmail pop up lots of "accept certificate" windows, so I added another davmail.property to silently accept certificates. Its very helpful in situations where the cert confirmation step has no value.

I'd be happy to contribute any/all of the above back to davmail (since it saves me A LOT of calendar pain)- #2 and #3 are easy, #1 may need some design work to come up with something thats adaptable to the SSO madness.

Thanks,

Greg

[Mickael Guessant]

Well, my idea for #1 was to refactor ExchangeSessionFactory and provide a new constructor in ExchangeSession:

/**
 * Build an ExchangeSession from an already authenticated HttpClient.
 *
 * @param httpClient httpClient instance with session cookies
 * @param userName User name
 */
public ExchangeSession(HttpClient httpClient, String userName) throws DavMailException {
    this.httpClient = httpClient;
    this.userName = userName;
    buildSessionInfo(null);
}

We could let users provide a custom authenticator to build this authenticated HttpClient instance and pass it to ExchangeSession...

For #2 users requested a way to have a single password change on password expiry, a shell script feels a bit too complex for most users.
Don't you think we could display a dialog to let users enter the new password, and then store it in a secure keystore ?

Although I do agree #3 is an easy way to workaround broken PKI setup, I am still reluctant to provide a standard way to disable security... maybe as a hidden property setting ?
Anyway, the real way to solve certificate issues is often to add CA certificates to Java cacerts.

Thanks for your feedback,

[gregm]

A custom authenticator sounds good, and a better idea than adding complexity to ExchangeSession. The existing buildLogonMethod and subsequent post is almost enough, the problem is the javascript built into the logon page adds a few items to the post's query string, so that has to be scraped out and added programatically. There is also a cookie protocol that httpClient handles, which thankfully doesn't affect davmail- but there is a refer header and davmail has to know enough about siteminder to know when authentication is complete and when to reattempt the original url. The executeFollow code in clientFacade is sufficient (with the addition of the refer header). That said, SSO's are probably going to differ widely- some have smartcards some not, some may have javascript others not- Siteminder doesn't fundamentally require it. I'd be inclined to propose a Siteminder-specific authenticator, incorporating some method of call-out to the user where idiosyncracies can be handled, eg jamming selections that the user will have had to make and marshalling the query string items for post. Our SSO requires about 6 querystring items to be present at post, some of which can only be gleaned from examining the javascript source and/or watching the http trace from a browser login. Successful authentication is signalled by the SMSESSION cookie being dropped, if it does not appear then authentication has failed and there is no fallback to another url.

a shell script for #2 is relatively simple in that decodeCredentials can begin with the caldav-supplied credentials, supercede with forceUser/forcePass (if they are supplied), then run the exec() (if it is supplied) which takes the user & pass as parameters- the script (or whatever) then accepts or modifies them as per the user's implementation and returns them. decodeCredentials then proceeds with the "effective" credentials. The win is davmail can then be operated on top of a local credential store, alongside other services like fetchmail, exim with no additional drama.

Its super important to me to allow unattended operation ie no dialogs, I find it helpful to run davmail in a vnc window- unattended- that I can connect to as required. Thats the motivation for #3 as well. There is no way my institutional network helpdesk could manage questions about or changes to cert setups- its completely off the table. So I have to be able to manage on my own. For example, our SSL certs have been expired for at least a year, we are instructed to just click accept- so it makes sense to me to have a brainless silent accept whenever there are cert changes. OTOH hidden properties would work fine for this, thats how I have them arranged now. When they are omitted from the config file (or if present and empty) standard davmail behavior applies.

I have 3 always-on clients running against davmail, 2 thunderbird/lightnings and davdroid/calendar on my phone, there are a couple other sometimes-on thunderbird/lightning systems- all of them hook up to my centralized imap/exim spools which use the centralized credentials, I need davmail to use the same system. Storing the credentials on the end systems means a laborious reentry of the password every 2 months, my institutional network requires 12+ chars, lots of difference relative to the last one, memory of last 10 or so changes etc- a real nuisance even when I'm local and can paste the password into the dialog box. With the local centralized system I do the password change in one location when I'm at the office.

I've not worked on sourceforge before, it seems as if I am supposed to check out the project in svn or git & commit changes but I can't imagine I would have rights to commit against the trunk, but a branch for later merge would make sense. Alternatively I'd be happy to arrange sending diff's if thats preferable.

Thanks!

[Mickael Guessant]

Sorry for the answer delay, your suggestions are very interesting.
I think I should first refactor ExchangeSession creation to make it easy to plug custom authenticator.

The tricky part is to separate authentication from other session init stuff...

[Christer Gustafsson]

Hello Gregm and Mickaeel,

I have similar problems with javascript based form login at my company OWA/application portal and starting to get brain damage from parsing the javascript code to get davmail working. Can I get you adaptations gregm to get me faster going? My company does not use the same frontend but it should be easy to adapt i think.

I'm able to use android apps like OWA Webmail and OWM Email to get access to the company site but not davmail :( But I'm not giving up!!

Best regards,
/Christer

[Christer Gustafsson]

Hello again!

I've solved my dilema with sime lost grey cells :)

It was two missing parameters in the auth login in post method. Its very usefull with http analysing software I found out!

Best regards,
/Christer