Generic approach for storing credentials
Posted: Wed Aug 29, 2012 2:45 pm
Hi folks,
we're currently developing several zimlets that integrate with other systems (eg. cms, erp, etc).
These zimlets (more precisely: their backend jsp code) need the proper user credentials to these
external systems.
For now, we're storing them in the user-zimlet-properties, but they can be accessed by frontend
javascript code, which imposes an security risk. So we'll need to move them to some other
datasource. Options are:
a) filesystem: a bit tricky to guarantee atomicity and not suited for multiserver (would require additional sychronization)
b) mailboxd database: not suited for multiserver, like w/ filesystem
c) ldap: requires schema extension (that must be maintained across zcs separate versions, more complex on zcs upgrades)
d) separate database server: quite complex to set up (far out of scope for a simple zimlet)
The first step we're probably going is to abstract away the access to such information, so we can choose the underlying actual storage later (maybe configurable or even supporting multiple ones).
Any ideas on this ?
Thanks.
we're currently developing several zimlets that integrate with other systems (eg. cms, erp, etc).
These zimlets (more precisely: their backend jsp code) need the proper user credentials to these
external systems.
For now, we're storing them in the user-zimlet-properties, but they can be accessed by frontend
javascript code, which imposes an security risk. So we'll need to move them to some other
datasource. Options are:
a) filesystem: a bit tricky to guarantee atomicity and not suited for multiserver (would require additional sychronization)
b) mailboxd database: not suited for multiserver, like w/ filesystem
c) ldap: requires schema extension (that must be maintained across zcs separate versions, more complex on zcs upgrades)
d) separate database server: quite complex to set up (far out of scope for a simple zimlet)
The first step we're probably going is to abstract away the access to such information, so we can choose the underlying actual storage later (maybe configurable or even supporting multiple ones).
Any ideas on this ?
Thanks.