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:[EMAIL PROTECTED] > Sent: Monday, October 27, 2003 12:29 PM > To: [EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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.
