Hi Alex > Nadar this is all great stuff. You should be working with us to bring this > about. Personally I'm working on an embeddable LDAP server based on Merlin > which I'm hoping can be incestuously reused for the security backing store > of Merlin as well as other containers even EJB servers. Perhaps we can > discuss this.
Well, the we actually did it in the project was to ask an EJB session bean as the security provider. Basically, it does not matter whether it is LDAP, database, backend system, a static policy file.... The way I see it, you need some abstraction of various components in the security: 1. Security Provider(s) 2. Security Facade 3. Security Brain (AccessController, SecurityManager, SecurityEngine or whatever you like to call it) Now what is what? 1. Security Provider is the provider of security. It provides Authenticator and/or Authroizer and/or Auditor. A valid question is whether Auditor should be a part of a Security Provider? I am personally not sure, but usually Audit function is as important as Authentication and Authorization although many organization never bother to audit. Now the system would definitely have more than one security provider, why? In a multi-application environment (like an EJB container), each application (call it Merlin-component), has usually its own security model and needs its own security provider. Say my banking application wants to talk to mybank.com and ask their CICS server for the security model at the same time that my telecom application asks the LDAP server in mytelecom.com. So you end up having one or more Security Providers. 2. Security Facade (or whatever you like to call it) would be responsible to abstract the communication with various Security Providers. Usually you do not want your applications to open up an URL or make a network connection using strange ports through your firewall to speak with strange security providers. You would probably want to control who is talking to whom. Furthermore, you would probably want to configure(declare) what application/component should ask which security provider. Another thing is that you would like to expose the same interface, so that if you change the provider or the providers' implementation, the application/component be kept almost intact. 3. Now, the last but the most important thing is the authorizer part which is kept in this Security Brain guy. Frankly, I cannot find a good name for it because all the good names (Access Controller and Security Manager) are taken by Java. Maybe Security Engine is good word? Anyway, Java sees at Access Controller as the guy the check the permission for a given CodeSource and Subject. Now the Sun's approach is very nice and powerful, but it is too abstract most organizations. If you come from a Role driven environment, say database people , they usually think to guard resources based on Role/Group privilege. In such environments, you usually make a distinction between the Guarded Resource (say a table), Access Controller List (RoleA has WRITE permission, RoleB has WRITE and DELETE permissions etc) and the Guard itself. Well, these things actually can be achieved with Java, but they are not directly provided with J2SE. However, J2EE provides to some degree these things through Method Level Security (you enforce security declaratively on each method in ejb-jar.xml). Well, there is a problem with J2EE (at least for a business application). Firstly, it does not support fine-grained security on object level (like) Best Regards -- Nader Aeinehchi Aasenhagen 66 E 2020 Skedsmokorset NORWAY Direct and Mobile +47 41 44 29 57 Tel (private): +47 64 83 09 08 Fax +47 64 83 08 07 www.aeinehchi.com ----- Original Message ----- From: "Alex Karasulu" <[EMAIL PROTECTED]> To: "'Avalon Developers List'" <[EMAIL PROTECTED]> Sent: Saturday, April 03, 2004 4:40 PM Subject: RE: Secure Kernel in Merlin > > > > -----Original Message----- > > From: Nader Aeinehchi [mailto:[EMAIL PROTECTED] > > 1. Merlin's Kernel is pretty limited, and not really worth adding any > > security > > > features, since the same can basically be done by the > > java.security.policy > > > file. > > > > 2. The interesting parts lies in the possibility to assign grants to > > 'components' > > > instead of codebases > > Still the same thing except your using the component's set of classes as the > code base specifier instead of using a package based specifier. But it is a > very convenient feature I agree we should have it. > > > 3. Next step is to make a facility which provides the JAAS style subject > > level > > > security > > Yep we might need to sprinkle a little bit of JAAS and JACC into this. > Personally I find Java security appalling and it does slow things down. I > do recommend that the ability to control security be on the level of service > methods like EJB in a way so it's not on all the time in places where you > don't need it to be. > > It might just however be better to just use a general security mechanism > free of all this crap so we don't run into conflicts when the container is > embedded into a J2EE container. > > > For a customer, I developed a security service that incorporated security > > in > > kernel (a factory would decide whether to start in security mode or not). > > This secure kernel is build on JAAS, also both codebase and subject as the > > secure kernel at boot reads the policy file (say from a database or a > > ldap) > > I like the LDAP idea :-) > > > and replaces the policy for the entire JVM. > > Furthermore, I developed an extended security manager that could provide > > addon features like method permission (similar to EJB declarative method > > permission) etc. One point I learnt from this project is that the > > underlying "components" may have a different security model than the > > kernel. > > Not only the authorization model may be different, but also each component > > may want to use a different authenticator. Based on that experience, I > > got > > the idea that a cascading security model should be provided, in which each > > component has its own security model that cannot violate the security > > constraints imposed by its surrounding container. > > > > The other thing I learnt was not to differentiate/favourize codesource > > with > > subject. After all, security is about WWW (Where codesource, Who subject, > > What guarded resource). > > > > Regarding "assign grants to 'components' instead of codebases", I would > > think you can solve it by a special purpose classloader. When a component > > is loaded by the classloader, simply assign the component its own > > codoesource, that is different from its physical codesource. A similar > > approach is taken in Sun's J2EE 1.3 reference application server. > > > > Nadar this is all great stuff. You should be working with us to bring this > about. Personally I'm working on an embeddable LDAP server based on Merlin > which I'm hoping can be incestuously reused for the security backing store > of Merlin as well as other containers even EJB servers. Perhaps we can > discuss this. > > Alex > > > > > --------------------------------------------------------------------- > 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]
