geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cabrera, Alan" <Alan.Cabr...@reuters.com>
Subject RE: Apache Geronimo Security
Date Mon, 27 Oct 2003 21:44:39 GMT
Hey Ed,

Would it help for us to have some use cases in our heads for this
discussion?  I see two.  First is an application client wishes use a remote
Geronimo server and wants mutual authentication and secure communication.
Second is a web server cluster wishes use a remote Geronimo server and wants
mutual authentication and secure communication.  I see SASL and GSSAPI as
the likely candidates.

The Geronimo security service will have already been configured to map
principals from security realms to sets of permissions, each set identified
by a role name, as outlined in JSR115.  Vanilla LoginModules that are
provided by the security realms are used to fill a Subject w/ its principals
and credentials.  The authenticated subject is associated w/ the call stack
by performing a Subject.doAs().  This will enable a variety of Web/EJB
Interceptors and contexts to perform simple permission checks to provide the
security screening needed.

To my mind, I do not see the advantage of adding yet another mapping layer
of principals and credentials on top of the security layer that already
provides everything that is needed.

I take exception to two points about our discussion so far; to my mind they
have no bearing as to whether SASL is the way to go or not.  First, is the
iterative mapping of principals until no more mapping can be performed.
Second is the iterative mapping of principals into permissions until no more
mapping can be performed.

> -----Original Message-----
> From: Edward Flick [mailto:directrix1@yahoo.com] 
> 
> Hey Alan,
> 
> --- "Cabrera, Alan" <Alan.Cabrera@reuters.com> wrote:
> > Some points about the recursive AuthDelegator:
> > 
> > - I don't like the idea of a mapper creating
> > credentials for a Subject.  I
> > think that the LoginModule should be the sole source
> > of credentials.
> The AuthDelegator could be a LoginModule, whereby the
> servers logs-in on behalf of the already authenticated
> (to the server) user's name as one of the Callback
> parameters.

Delegation is one of the things that comes w/ GSSAPI.  While AuthDelegator
could be a LoginModule, your reply does not speak to my assertion that the
LoginModule should be the sole source of credentials.  For example, a third
party LoginModule should generate its own credentials.  AuthDelegator, under
the guise of being a LoginModule, shouldn't put them in as the result of an
iterative principal mapping mechanism.

Let me also add that this mechanism of an AuthDelegator is a work-around for
SASL to obtain functionality that GSSAPI already provides.

> > - It seems that the recursive paradigm also
> > generates permissions, e.g.
> > Principal AllowedService "Reporting".  IMHO this is
> > bad form, mixing
> > identification information w/ authorization
> > information.
> Well, it was just an example, but I really don't see
> how this particular example could be bad.  The Policy
> class is just a mapper also.  

My point was that they should be separate.  The fact that both the
iteratively mapping of Principals and the Policy class mapping principals to
permissions both use a "map" paradigm, does not mean we should lump them
together.  Mixing the two strikes me as just plain bad.

> If the user can't edit
> their own Subject (and in a secure situation they
> shouldn't be allowed too), then how can this open
> anything up besides easier access to a more
> descriptive Subject.  Also, Principal AllowedService 
> "Reporting" won't do anything if its not granted rights to 
> begin with, so I still don't see how its crossing the line.

I also don't see a security hole, however, it's the *iterative* mapping of
principals until no more mapping can be performed and the mixing of
principal mapping and permissions that I take exception to.

> > - Iteratively mapping Principals makes security
> > management very difficult to
> > know a priori what will be granted to an individual.
> I disagree to an extent.  It seems overly easy to map,
> if you ask me.  It makes specific exceptions easy to
> see.  And it keeps the list nice and compact.  But it
> would require jumping around in a text file if that's
> how you edit the mapping, but I would think that a
> specialized editor could very easily be made.

A simple map from one security realm to another in a federated system is one
thing, the iterative mapping of principals until no more mapping can be
performed is quite another.  Iteratively mapping them into permissions is
just plain bad and does not mesh well with JSR115.  

> > AFAICT SASL does not provide a mechanism for
> > transfer of the credentials
> > that have been generated by the LoginModule to the
> > Subject.  As I have
> > stated before, I feel strongly that the LoginModule
> > should be the sole
> > source of credentials.
> > 
> But the association of the credentials/principals with
> a Subject is trivial.  It requires a piece of code
> with enough privilege to do it (it could be a
> LoginModule).  
> 
> Edward
> 
> > 
> > Regards,
> > Alan
> > 
> > > -----Original Message-----
> > > From: Edward Flick [mailto:directrix1@yahoo.com]
> > > Sent: Monday, October 27, 2003 12:29 PM
> > > To: geronimo-dev@incubator.apache.org
> > > Subject: Apache Geronimo Security
> > > 
> > > 
> > > Hey Alan,
> > > I'm just going to go ahead and redirect this
> > > conversation to the list.
> > > 
> > > In general I would almost say that we would be
> > > emulating GSSAPI with the security model, but
> > there
> > > are a lot of SASL libraries out there with a lot
> > of
> > > SASL authentication mechanisms, whereas GSSAPI
> > seems
> > > to only support KRB (and a couple others) for the
> > time
> > > being (although it can be extended).  I just know
> > that
> > > they essentially both get the same end result
> > anyways,
> > > an authenticated identity, but SASL has quite a
> > bit
> > > more code working for it (and they are going to be
> > > putting the SASL API into JDK1.5, so even Sun is
> > > thinking about it).  Also SASL does have GSSAPI
> > over
> > > SASL mechanism, so you can get the best of both
> > worlds
> > > with SASL.  The only real difference is you would
> > need
> > > to take the authenticated identity and have a
> > > privileged class wrap it in a principal and
> > associate
> > > it with the current Subject, which is a trivial
> > task.
> > > 
> > > As far as the GeronimoAuthenticatedPrincipal goes,
> > I
> > > would say that we would only need one form for the
> > 
> > > authenticated principal because of the recursive
> > > PrincipalDelegator.  I guess a better explanation
> > of the
> > > recursive PrincipalDelegator (maybe it should be
> > called
> > > recursive AuthDelegator) could be given through an
> > example:
> > > 
> > > 1) A remote user initiates a session with the
> > server
> > > 2) Remote user authenticates via SASL
> > > 3) Server sets up GeronimoAuthenticatedPrincipal
> > with
> > > users username (lets call him "bob"), and passes
> > it
> > > into the recursive AuthDelegator
> > > 4) The recursive AuthDelegator looks up any
> > > supplementary Principals and Public/Private
> > > Credentials to be associated with/or denied from
> > > GeronimoAuthenticatedPrincipal "bob"
> > > 5) It finds the following Principals/Credentials
> > which
> > > belong to GeronimoAuthenticatedPrincipal "bob"
> > >    Principal AccountNumber "117"
> > >    Principal RoleName "Customer"
> > > 6) It then performs the same lookups on these
> > > Principals
> > >   Search Principal AccountNumber "117"
> > >     PrivateCredential NetworkPassword "jimbo"
> > >   Search Principal RoleName "Customer"
> > >     Principal AllowedService "OrderEntry"
> > >     Principal AllowedService "Reporting"
> > > 7) It then searches on the 3 items returned from
> > this
> > > and since it doesn't find anything else to
> > recursively
> > > associate it returns the entire set of recursively
> > obtained
> > > Principals/Credentials
> > > 
> > > 8) Elevated privileged class associate entire
> > > Principal/Credential set with current Subject
> > > 9) We have now extracted all the User meta-data /
> > > security attributes we need into the Subject from
> > one
> > > authenticated Principal (and best of all we do
> > this without
> > > any details of the actual inner workings of the
> > > AuthDelegator, it could be using an
> > ActiveDirectory or LDAP
> > > source, or an RDBMS or whatever particular
> > implementation you choose).
> > > 10) Process commands as Subject
> > > 
> > > What do you guys think?
> > > 
> > > Edward Flick
> > > 
> > > --- "Alan D. Cabrera" <adc@toolazydogs.com> wrote:
> > > > Hey Ed,
> > > > 
> > > > There is no mailing list other than the geronimo
> > > > list.  We can move this
> > > > discussion over to there.  I was thinking of
> > having
> > > > a little chat w/
> > > > you, which we are having, before we moved the
> > > > discussion to the group.
> > > > 
> > > > Concerning GeronimoAuthenticatedPrincipal, there
> > > > could be multiple
> > > > Principals and it seems kind of artificial to
> > keep
> > > > it at just one.  My
> > > > impression of SASL is that it's great as a
> > general
> > > > secure connection
> > > > mechanism, if you don't care about the details
> > and
> > > > just want things to
> > > > work.  If you care about the details but still
> > need
> > > > a pluggable
> > > > interface, GSSAPI is the way to go.  If working
> > with
> > > > Subjects/Principals is a requirement, it strikes
> > me that we would be
> > > > trying to make SASL do
> > > > what GSSAPI was meant to do.  Thoughts?
> > > > 
> > > > The idea of a recursive PrincipalDelegator
> > sounds
> > > > interesting but, I
> > > > don't quite understand it fully.  Can you
> > provide
> > > > more details?
> > > > 
> > > > -----Original Message-----
> > > > From:	Edward Flick
> > > > Sent:	Fri 10/24/2003 11:41 AM
> > > > To:	Alan D. Cabrera
> > > > Cc:	
> > > > Subject:	RE: Apache Geronimo Security
> > > > Well, right I understand that.  I was just
> > saying
> > > > that
> > > > SASL is security architecture agnostic.  It just
> > authenticates and
> > > > returns the identity of the person logging in as
> > a String, and we
> > > > could create the Principal and associate it with
> > the current Subject
> > > > at
> > > > that time.  But we could do it with a custom 
> > > > GeronimoAuthenticatedPrincipal (or whatever we'd want
> > > > to call it) instead of whatever a particular
> > > > authentication scheme normally forces onto you.
> > > > 
> > > > Also, I think that on the server side having a
> > > > recursive PrincipalDelegator (to delegate other Principals 
> > > > associated with the Subjects current
> > set
> > > > of
> > > > Principals) would enable a single
> > > GeronimoAuthenticatedPrincipal to be
> > > > able to associate
> > > > a wealth of identity information with the
> > Subject
> > > > (kind of offtopic, but this is the approach I'm
> > > > using
> > > > with Apache's AltRMI [although its not in cvs,
> > > > yet]).
> > > > What do you think?  And do you know of a mailing
> > > > list
> > > > for this?
> > > > 
> > > > Edward Flick
> > > > 
> > > > --- "Alan D. Cabrera" <adc@toolazydogs.com>
> > wrote:
> > > > > JSR115 basically pushes all the web/ejb
> > security
> > > > > into the Policy class.
> > > > > This means that we have to use Principals to
> > do
> > > > > security checks to see
> > > > > if web page hits or EJB calls are allowed.
> > > > > 
> > > > > I liked GSSAPI because I can get the
> > authenticated
> > > > > Subject and its
> > > > > Principals for these checks.  GSSAPI is not
> > > > > necessarily TPA you can drop
> > > > > in a variety of mechanisms.  Kerberos is just
> > one
> > > > of
> > > > > the required
> > > > > implementations.
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From:	Edward Flick
> > > > > Sent:	Mon 10/20/2003 11:39 AM
> > > > > To:	Alan D. Cabrera
> > > > > Cc:	
> > > > > Subject:	Re: Apache Geronimo Security
> > > > > Hi Alan,
> > > > > Well, SASL doesn't really even use the Subject/Principal 
> > > > > paradigm.  It just returns
> > an authenticated
> > > > > identity (a string identifying the
> > > > > person) using a variety of mechanisms
> > > > transparently.
> > > > > 
> > > > > There is even a GSS mechanism for SASL, so
> > > > Kerberos
> > > > > auth is not out.  The reason I think SASL is
> > ideal
> > > > > is
> > > > > because when you authenticate you just get a
> > > > string
> > > > > that is the userid, and it is not
> > automagically
> > > > > introduced into a Subject.  So you could
> > create a
> > > > > custom principle type specifically for
> > Geronimo
> > > > and
> > > > > store it in that.  Also, GSSAPI seems very
> > heavily
> > > > > geared at a three party auth system (read
> > > > kerberos).
> > > > > 
> > > > > Whereas, there are many SASL mechanisms
> > already
> > > > > available (for 2 and 3 party auth), and you
> > can
> > > > just
> > > > > drop in a different SASL provider jar to get
> > > > support
> > > > > for them.  BTW, is there a geronimo security
> > list?
> > > > > 
> > > > > --- "Alan D. Cabrera" <adc@toolazydogs.com>
> > wrote:
> > > > > > Hi,
> > > > > >  
> > > > > > I'm tossing around ideas about the Apache
> > > > Geronimo
> > > > > > Security for securing
> > > > > > calls to the container.  I noticed that you
> > are
> > > > > > strongly in favor of
> > > > > > SASL.  Let me toss some thoughts out and
> > warn
> > > > you
> > > > > > that I am not entirely
> > > > > > familiar w/ SASL.  I'm thinking that GSS-API
> > > > might
> > > > > > be the way to go.
> > > > > > The reason is that it seems that I have more
> > > > > direct
> > > > > > access to the
> > > > > > Subject/Principals in GSS-API than in SASL.
> > > > While
> > > > > > GSS-API can run under
> > > > > > SASL, I do not see how I can simply get
> > access
> > > > to
> > > > > > the Subject/Principals
> > > > > > like I can in GSS-API.
> > > > > >  
> > > > > > What are your thoughts?
> > > > > >  
> > > > > >  
> > > > > > Regards,
> > > > > > Alan
> > > > > >  
> > > > > >  
> > > > > 
> > > > > 
> > > > > =====
> > > > > Edward Flick
> > > > > Enterprise Applications Designer / Database 
> Administrator / Web
> > > > > Administrator
> > > > > CDF, Inc.
> > > > > 
> > > > > __________________________________
> > > > > Do you Yahoo!?
> > > > > The New Yahoo! Shopping - with improved
> > product
> > > > > search
> > > > > http://shopping.yahoo.com
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > > ATTACHMENT part 2 application/ms-tnef
> > > > name=winmail.dat
> > > > 
> > > > 
> > > > 
> > > > =====
> > > > Edward Flick
> > > > Enterprise Applications Designer / Database
> > > > Administrator / Web
> > > > Administrator
> > > > CDF, Inc.


---------------------------------------------------------------- 
      Visit our Internet site at http://www.reuters.com 

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit <http://www.reuters.com/messaging> 

Any views expressed in this message are those of  the  individual sender,
except  where  the sender specifically states them to be the views of The
Reuters Group.

Mime
View raw message