Sandy, Since my posting really only pertained to NT auth, this discussion is pointless if Nikhil is using something else for his portal. Just to see where the discussion goes...
> Well, the server has to know the clear-text password during the > original login, no? This is where I was suggesting a double-post at > login, or at holding the creds in a server var on the portal to be > posted later. If the portal code can't be modified, you could do this > using a sort of super-portal page that's all custom code and does the > double-post. However... If the authentication is integrated with NT, the application should never see the password. Having the user login using clear-text to your server will introduce the security holes you were referring to below, but let's leave that out for now :) If you're running IIS for your portal you will either have to write custom auth code, or wrappers for the session since your super-portal would now be the client to the existing portal server. One of the benefits in using integrated auth in NT in the first place is to remove the hassle of writing code for authentication and page / script security. It seems easier to take advantage of this instead of duplicating it. > > When the user clicks on "email" a server-side script writes a random > > unique password associated with the user's IMail account. The userid > > and password are then used to create a session with the IMail > > server. > > ...this approach is flawed--or maybe you just left out a step?--since > you have to ensure that the creds are actually *valid* against the > portal back end before trusting them. So you need to be able to > validate them once against the portal, decide from that response > whether to trust them, *then* replicate them to IMail and post them > again to the portal login and IWEBMSG login. Annoying work. (And I > could think of some security holes here, but let's leave that out for > now.) In order to gain access to the portal, and thus access to email, they have already been authenticated against the portal auth (so creds are *valid*). The solution I proposed takes into account two scenarios: session handoff directly to HTTP client to access the IMail server directly, as well as proxy-like configuration where the portal is the client to IMail where the user cannot directly access IMail. If the portal server is the only client, the passwords really don't matter - and can even all be the same - so long as you secure the connection and authorization between the portal service and IMail server. The approach of setting random passwords per session is really only necessary if you are not trusted with the user's real password, as in NT, and the user is able to connect directly to the IMail server. So if you don't know what the original password or password policies are for that user, setting a random password per session in the ODBC auth table is an excellent way to protect user authorization without knowing original password policies. If the ODBC passwords are set only from a system account for pre-authenticated sessions, what are the specific holes? By setting expire times on the ODBC password (or even immediately expiring the ODBC password after IMail session is obtained), you garantee that each session with IMail is valid according to the remote authentication mechanism. For example: if the portal account had been disabled the user couldn't logon to the portal, wouldn't be able to click on the email button - which wouldn't set a valid password in IMail's ODBC table, and wouldn't gain access to email... even if they attempted to connect directly to IMail using variables sniffed off their own web client from a previous session. This avoids more complicated methods of integrating the two authentication methods. This also entirely removes the task of password administration for the extended IMail ODBC table. If you have strict NT pw policies, this is easier than writing scheduled apps to manage passwords used for the ODBC auth, where the portal looks up the associated password and grabs a session for the user. If this is too complex for the environment, or such security isn't necessary, you could just generate random passwords for each user with a really long string, making it difficult to guess or crack with brute-force (but this doesn't expire access to IMail by that user if their portal account has been disabled). > What I'd like to know is whether the portal can use ANY LDAP server > for auth. If so, set it up to point to AD, make the IMail box a DC, > and use IMail's NT integration. This will ensure that no passwords > ever have to be written out, replicated, dummied up. But nothing will > alleviate the need to cross-post or double-post the credentials to > both web servers. This doesn't solve the original problem of single-signon for the duration of the whole session for both portal and email access (see your first response). If you run IMail NT auth, you will need to login twice, unless you use Jason's approach (which is an excellent approach and would work for NT auth too, but also permanently binds your portal to the functionality and performance of IMail's authentication - and may cause session / realm issues if the rest of your portal is on a different servers with protected or secure pages under a different auth scheme). My suggestion only works for an HTML only implementation of IMail, but works very well for systems not directly trusted by NT (it's just a simple & secure way of extending an authentication token outside of NT for the duration of that session). This also allows the portal to remain intact, with whatever security policies are already in place. Obviously, one should try and put everything under the same authentication mechanism when possible - so long as you don't loose required functionality or introduce new security risks. Nikhil, for this very reason... we decided to give up on the single-session access to portal & email. Such customization would be a burden and would require continual development if IMail's handling of HTTP session logons change in future versions. In moving from an environment with multiple accounts and passwords, we determined it was more important to have secure integrated authentication for one account / password than it was to logon only once across multiple authentication mechanisms. -ives To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
