Page Comparison

...

Customize the mail account templates in WEB-INF/context/portlet/mailservers.xml. The default mailservers.xml contains examples.

Encrypting User Mail Account Passwords

If you let your users add their own mail accounts then it is likely that they will be storing passwords as well. This means you should really have some level of security on the passwords that are stored. Hopefully you also have your server environment and database locked down among other things, and this is just a little icing on the cake.

If right now you are scared, don't be. With the default configuration of MailPortlet, the following change to set the AES encryption key is the only change you should have to make to the configuration to get it up and running and letting your users connect to their Gmail, AOL, ISP, etc. accounts, although you may want to customize it more, which is why there are other steps below.

Here is an example of a 40-byte hex key that someone might put into WEB-INF/context/portlet/mailsecurity.xml for 128-bit AES encryption, but USE YOUR OWN KEY - do NOT use the 1f1f1f... provided here. If you use 1f1f1f... then you may as well not have encrypted the passwords at all:

...

Account Properties

fixed

If you have some way for the user to authenticate without information from them then it is there by default and is a "fixed" account. (Fixed accounts should not require any editing or additional user information.)

If you want to offer any email service to a user that requires additional information, it should not be fixed to avoid the user having errors upon first connection.

Now if someone wanted to, they could contribute a feature to show one or more mail tabs by default that require additional information, but that feature isn't there now. I can see how such a feature might be a good idea in some situations, but for most, I'd imagine the current functionality is probably adequate, since you can do roughly the same thing by just requiring that the user click on add/remove account and add that account.

For non-fixed accounts, you have full ability to default any field to any value so that when the user adds a new account of that type, they have things pre-filled-in, with the exception of password (which is basically a normal password field so it clears when the page reloads).

custom

If you set custom to true <property name="custom" value="true"/> then the user can edit more fields. If it is false, then they can only specify the name of the account, the account's username, and password.

includeInDefault

This was an artifact of earlier development, does nothing, was included as a property up to 2.0.0-alpha-7, but after that was removed for future releases. Please remove it from all of your configuration.

Encrypting User Mail Account Passwords

If you let your users add their own mail accounts then it is likely that they will be storing passwords as well. This means you should really have some level of security on the passwords that are stored. Hopefully you also have your server environment and database locked down among other things, and this is just a little icing on the cake.

If right now you are scared, don't be. With the default configuration of MailPortlet, the following change to set the AES encryption key is the only change you should have to make to the configuration to get it up and running and letting your users connect to their Gmail, AOL, ISP, etc. accounts, although you may want to customize it more, which is why there are other steps below.

Here is an example of a 40-byte hex key that someone might put into WEB-INF/context/portlet/mailsecurity.xml for 128-bit AES encryption, but USE YOUR OWN KEY - do NOT use the 1f1f1f... provided here. If you use 1f1f1f... then you may as well not have encrypted the passwords at all:

...

    <bean name="encryptionTool" class="org.jasig.portlet.mail.encryption.impl.AesEncryptionToolImpl">
        <!-- REPLACE THIS KEY WITH A KEY YOU MAKE UP IN HEX THAT IS THE SAME LENGTH. THIS LENGTH OF KEY IS ONLY ALLOWED IN THE U.S. -->
        <property name="key" value="1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f1f"/>
    </bean>
...
</beans>

...

Be sure that "exampleProxyTicket" is replaced with the UserInfo key that holds the MailServer password. Note that it currently gets the username by calling getRemoteUser() on the PortletRequest. If you would like the UserInfoCredentialsService to get the username from somewhere else, contact us (see the Feedback section).We suggest that this attribute contain a password that a token that can only be used for the current login session. Passing in a plain-text password via UserInfo is probably not a good idea (for example- what if there were something outputting UserInfo to the screen for debugging purposes in another portlet- then the mailpassword would show up on the screenthat holds the MailServer password. Note that it currently gets the username by calling getRemoteUser() on the PortletRequest. If you would like the UserInfoCredentialsService to get the username from somewhere else, contact us (see the Feedback section).

We suggest that this attribute contain a password that a token that can only be used for the current login session. Passing in a plain-text password via UserInfo is probably not a good idea (for example- what if there were something outputting UserInfo to the screen for debugging purposes in another portlet- then the mailpassword would show up on the screen).

Integrating with Your SSO Solution

• First discuss with your provider's mail server support about how you could provide a ticket to use as the password to the POP/IMAP server, so that the portlet (the server) could request email from that mail server, with the intent being for the MailPortlet to display the users' mail message subjects, senders, and datetime sent (and it supports display of a few standard IMAP flags). Webmail is totally separate from this request. While the user's HTTP/HTTPS request to the portal may contain the information needed to authenticate to the mail server, when it gets to the portlet itself, the portlet is making a connection to the POP/IMAP server (via JavaMail, which the portlet makes fully configurable to connect however you want, but typically is via POP3/POP3S/IMAP/IMAPS) and to connect and retrieve mail, it will require a username and password of some sort, the username being the user's mail account username most likely, and a password (in this case, a ticket).

• Then you want to determine how you are going to provide that ticket to the portlet. If you use UserInfo to do it, use that class in the config (that's what you would use with Shibboleth for example).

• If needed (probably not) you can write your own java class to assist with authN and/or password encryption. The MailPortlet is customizable and pluggable, and all JavaMail properties can be configured per account if needed, so the options are pretty wide-open (if you find a way to get the authN info to the portlet, it can fully utilize the JavaMail to do whatever JavaMail can do to get messages from whatever source you want- JavaMail is also pluggable for non-standard message protocols).

CSS

We tried our best to use some sort of uPortal standard styling that would be most compatible with existing and custom skins.

...