Re: application security gone mad
Gary, First let me say this is not a specific tomcat question, rather, a general application security issue that I'd like to get some feedback on. As I type is in, it's making me even MORE nuts! Am I? Was there a question in here, somewhere? :) No, you're not nuts but trying to follow any logic in this system certainly has a propensity to drive you mad. That seems *way* over complicated. Would you care to enlighten us as to why the process is so complex? Something like well, out EJB server doesn't like anonymous connections, so each person gets their own... would help at least me understand why you don't just something simpler. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: application security gone mad
The long and the short of it is: There will be an infinite number of application users. (maybe a few less) They will have 1-n roles. Let say 3 . There are a finite number of proxy EJB access users. As mentioned earlier, derived from the application user roles. The method level security for EJB access will be based on the proxy user's roles. So... 3 application user roles ... 9 proxy EJB access users. Why not simpler IS the question. Like configuring a single java.naming.security.principal and java.naming.security.credentials in a single jndi.properties file for a single application. And, managing web application security via web.xml security-constraint. DUH! CASE CLOSED. It's not just complicated... it's NOT container managed security... it's NOT configurable what if a user has NO roles? gary... From: Christopher Schultz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] Date: Fri, 14 Nov 2003 11:12:33 -0500 To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: application security gone mad Gary, First let me say this is not a specific tomcat question, rather, a general application security issue that I'd like to get some feedback on. As I type is in, it's making me even MORE nuts! Am I? Was there a question in here, somewhere? :) No, you're not nuts but trying to follow any logic in this system certainly has a propensity to drive you mad. That seems *way* over complicated. Would you care to enlighten us as to why the process is so complex? Something like well, out EJB server doesn't like anonymous connections, so each person gets their own... would help at least me understand why you don't just something simpler. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: application security gone mad
Gary, WOW, how could one possibly justify/rationalize the complicated approach you described in your original post? The architecture as described makes no real use of CMS. Sounds like a combination of not invented here and I don't understand it so I'm not gonna use it. You're on the right track, hope you prevail. Is JAAS being used? Robert Gary Hardy wrote: The long and the short of it is: There will be an infinite number of application users. (maybe a few less) They will have 1-n roles. Let say 3 . There are a finite number of proxy EJB access users. As mentioned earlier, derived from the application user roles. The method level security for EJB access will be based on the proxy user's roles. So... 3 application user roles ... 9 proxy EJB access users. Why not simpler IS the question. Like configuring a single java.naming.security.principal and java.naming.security.credentials in a single jndi.properties file for a single application. And, managing web application security via web.xml security-constraint. DUH! CASE CLOSED. It's not just complicated... it's NOT container managed security... it's NOT configurable what if a user has NO roles? gary... From: Christopher Schultz [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] Date: Fri, 14 Nov 2003 11:12:33 -0500 To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: application security gone mad Gary, First let me say this is not a specific tomcat question, rather, a general application security issue that I'd like to get some feedback on. As I type is in, it's making me even MORE nuts! Am I? Was there a question in here, somewhere? :) No, you're not nuts but trying to follow any logic in this system certainly has a propensity to drive you mad. That seems *way* over complicated. Would you care to enlighten us as to why the process is so complex? Something like well, out EJB server doesn't like anonymous connections, so each person gets their own... would help at least me understand why you don't just something simpler. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: application security gone mad
Robert, You hit it on the head... And, prevail? not a chance, they're a client... I'm the consultant. And, JAAS? Please. We can't even agree about CMS. The posting was 1) a rant. 2) fishing for a little parting wisdom (not mine) to leave with them to think about. CMS is fine just the way it is. And, a pooled DAL that uses a single, configurable uid p/w per application seems pretty standard I'd say. gary... From: Robert Hall [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] Date: Fri, 14 Nov 2003 10:17:04 -0800 To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: application security gone mad Gary, WOW, how could one possibly justify/rationalize the complicated approach you described in your original post? The architecture as described makes no real use of CMS. Sounds like a combination of not invented here and I don't understand it so I'm not gonna use it. You're on the right track, hope you prevail. Is JAAS being used? Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: application security gone mad
Gary, A pooled Data Access Layer (ie EJB's) is pretty standard, but I'd prefer a uid p/w that was not unique to an app. For example, using kerberos to authenticate, LDAP for course grained authorization, and a DB for finer grained authorizations. But wait, that would mean they'd have to use JAAS! Regards, Robert Gary Hardy wrote: Robert, You hit it on the head... And, prevail? not a chance, they're a client... I'm the consultant. And, JAAS? Please. We can't even agree about CMS. The posting was 1) a rant. 2) fishing for a little parting wisdom (not mine) to leave with them to think about. CMS is fine just the way it is. And, a pooled DAL that uses a single, configurable uid p/w per application seems pretty standard I'd say. gary... From: Robert Hall [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] Date: Fri, 14 Nov 2003 10:17:04 -0800 To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: application security gone mad Gary, WOW, how could one possibly justify/rationalize the complicated approach you described in your original post? The architecture as described makes no real use of CMS. Sounds like a combination of not invented here and I don't understand it so I'm not gonna use it. You're on the right track, hope you prevail. Is JAAS being used? Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
