geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Flick <directr...@yahoo.com>
Subject RE: Apache Geronimo Security
Date Mon, 27 Oct 2003 19:03:52 GMT
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.

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

> - 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 thats
how you edit the mapping, but I would think that a
specialized editor could very easily be made.

> 
> 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/prinipals with
a Subject is trivial.  It requires a peice 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.
> > > 
> > > __________________________________
> > > 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.


=====
Edward Flick
Enterprise Applications Designer / Database Administrator / Web Administrator
CDF, Inc.

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

Mime
View raw message