Jacob Hookom wrote: > The basic goal is to keep people from walking through id's of objects > passed as params.
The id's should also be POSTed or pushed along in form beans or hidden fields, not visible in querystrings. Also, if your authorization machinery is good enough, this should be harmless -- i.e., id=25 data should be accessible only to user authorized to access id=25. >The realm is built to handle all of the > authorization, I just would like to keep as little as possible in the > session and prevent redundant checking against the persistent source. There is sort of a basic tradeoff that you face here. The most secure setup is to encode only the user's identity in the session token, but this forces the security system to look up the auth profile for each request. Most commercial products and large-scale sites (and, I think Tomcat, as well -- someone can correct me if I am wrong) do some caching in their authorization management infrastructure to limit database hits. If what you are concerned about is limiting database I/O, you should consider implementing profile caching in the authorization service. This way, you can still just push identity info to the browser. > > | -----Original Message----- > | From: Phil Steitz [mailto:[EMAIL PROTECTED]] > | Sent: Friday, September 06, 2002 2:41 PM > | To: Struts Users Mailing List > | Subject: Re: [OT] Request Certificates/Security > | > | Jacob, > | > | Assuming that you have exhausted *all* means to solve your > authorization > | problems using container-managed security, which would eliminate the > | need to muck with security tokens, here are some comments on your > setup: > | > | 1. Use a secure session cookie to carry the security token. You > should > | keep this stuff out of the queryString. > | 2. You need to encrypt, not hash the authorization profile info in the > | cookie, otherwise your authorization manager will not be able to get > it > | back. <FRIDAY>Have fun managing the keys!</FRIDAY> > | 3. I would consider keeping the authorization info in a security store > | and encoding only the id in the security token. But then again, this > is > | really what container-managed security does :-) > | 4. I would recommend keeping the authorization timeouts short -- > hitting > | the DB to refresh auth profiles. This is more secure and also allows > | you to cut off access more quickly. If your tokens are valid for an > | hour, then privilege revocation can take up to an hour to become > | effective. > | > | > | hth, > | > | Phil > | > | Jacob Hookom wrote: > | > I know I beat security like a dead horse, but.... > | > > | > If my app generates a menu specific to the user, i.e., a project > list > | > that they belong to, then instead of creating a link to the > | > project.do?id=25, do you think it would be secure enough if I passed > a > | > huge "certificate" instead that had an hour time limit on it? The > link > | > would instead be: > | > > | > project.do?id=AJEIKL46642K32343OIN4 > | > > | > (Where the project uid is hashed with a timestamp and their role as > the > | > param) > | > > | > I know some developers use it when they are securing sites that span > | > multiple servers, but for this, it would prevent redundant db access > at > | > best. > | > > | > Does anyone else use this method? > | > > | > Jacob Hookom > | > Comprehensive Computer Science > | > University of Wisconsin, Eau Claire > | > > | > > | > > | > --- > | > Outgoing mail is certified Virus Free. > | > Checked by AVG anti-virus system (http://www.grisoft.com). > | > Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 > | > > | > > | > > | > -- > | > To unsubscribe, e-mail: <mailto:struts-user- > | [EMAIL PROTECTED]> > | > For additional commands, e-mail: <mailto:struts-user- > | [EMAIL PROTECTED]> > | > > | > | > | > | > | -- > | To unsubscribe, e-mail: <mailto:struts-user- > | [EMAIL PROTECTED]> > | For additional commands, e-mail: <mailto:struts-user- > | [EMAIL PROTECTED]> > | > | --- > | Incoming mail is certified Virus Free. > | Checked by AVG anti-virus system (http://www.grisoft.com). > | Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 > | > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
