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 18:11:03 GMT
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.
- It seems that the recurusive paradigm also generates permissions, e.g.
Principal AllowedService "Reporting".  IMHO this is bad form, mixing
identification information w/ authorization information.
- Iteratively mapping Principals makes security management very difficult to
know a priori what will be granted to an individual.

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.


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.
> > 
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product
> > search
> > http://shopping.yahoo.com
> > 
> > 
> > 
> > 
> 
> > ATTACHMENT part 2 application/ms-tnef
> name=winmail.dat
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears 
> http://launch.yahoo.com/promos/britneyspears/
> 


---------------------------------------------------------------- 
      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