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