Update: In regards to portlets, especially those that do DB connections, load
override property values from a location outside the war similar to the way
uPortal does (see
https://wiki.jasig.org/display/UPM41/Properties+Files+and+Properties+Overrides),
I propose we change the Apereo portlets to load property values in the Spring
configuration from
* local property files in war
* ${CATALINA_HOME}/portal/overrides.properties
* ${CATALINA_HOME}/portal/{portletName}_overrides.properties
* ${PORTAL_HOME}/overrides.properties
* ${PORTAL_HOME}/{portletName}_overrides.properties
The reason is that the main values that will be in the overrides.properties
file will be the following
hibernate.connection.driver_class=${environment.build.hibernate.connection.driver_class}
hibernate.connection.url=${environment.build.hibernate.connection.url}
hibernate.connection.username=${environment.build.hibernate.connection.username}
hibernate.connection.password=${environment.build.hibernate.connection.password}
hibernate.connection.validationQuery=${environment.build.hibernate.connection.validationQuery}
hibernate.dialect=${environment.build.hibernate.dialect}
(and some others for other uPortal Aggregation DB connections) and these
property names are the same property names that are used by uPortal and
portlets. The property value will be whatever the override value is, not the
build environment string.
This allows the common use case of having one file that applies to uPortal and
all portlets and sets the DB connection url (optional in case you want to make
it more 'hidden'), username, and password for maintenance (one file to change
when DB passwords change) and improved security (more restricted file access to
sensitive info). The {portletName}_overrides.properties allows for the rare
case of needing something else. One example that I can think of is an
encryption key value used by a portlet to encrypt sensitive user portlet
preferences before storing them into the DB, though I could also see having
that be global, or a conflicting property name between a couple of portlets.
Please let me know if you have any feedback on this idea.
Thanks,
James Wennmacher - Unicon 480.558.2420
----- Original Message -----
From: "James Wennmacher" <[email protected]>
To: [email protected], [email protected]
Sent: Monday, December 15, 2014 11:37:14 AM
Subject: More securely handling storage of sensitive information
I'm going to be incorporating code to handle Exchange Impersonation in
Exchange Web Services in the Calendar portlet. The current
implementation stores the the username and password in a properties
file. Since this is such a powerful trusted account, I'd like to
improve the security a bit above that implementation. What have others
done? Has anyone implemented something that I can package into the
portlet utilities project to improve the security aspects of storing
credentials?
What I was thinking of doing was having an encryption key stored in
portlet preferences and the encrypted password in a properties file,
plus the option of retrieving the properties files values from
${CATALINA_HOME}/portlet/{portletName}_overrides.properties and
${PORTLET_HOME}/{portletName}_overrides.properties. This certainly
isn't perfect, but at least it prevents someone who gets access to the
file system from easily obtaining the credential values without some
additional work and another knowledge barrier to overcome. It also
allows for different encryption encryption keys for different portlets.
I'd love to do something like this for the DB credentials as well, but I
haven't looked into the possibility of that.
Thoughts on this approach? I'm hoping someone might have already done
something and hopefully can share their solution, even if it is just a
partial.
Thanks,
--
James Wennmacher - Unicon
480.558.2420
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
