avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nader Aeinehchi" <na...@aeinehchi.com>
Subject Re: Secure Kernel in Merlin
Date Sat, 03 Apr 2004 22:19:07 GMT
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" <aok123@bellsouth.net>
To: "'Avalon Developers List'" <dev@avalon.apache.org>
Sent: Saturday, April 03, 2004 4:40 PM
Subject: RE: Secure Kernel in Merlin


>
>
> > -----Original Message-----
> > From: Nader Aeinehchi [mailto:nader@aeinehchi.com]
> > 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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message