Really a users@ question, so I won't bother to reply inline. What Jack wants is pretty much an enhanced version of UserDatabase. He can do much of what he wants with a really fancy custom UserDatabase, but would need changes to do more advanced X509 stuff (also, the current config wouldn't be as nice as he would want).
"Mark Thomas" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Jack wrote: >> When we use client-cert, we might be not using ssl at all since we don't >> ask >> confidential transfer. > This is not correct. CLIENT-CERT authentication *requires* ssl. ssl is > still ssl even if NULL encryption is used. > >>>A web application may well have a mixed user community, >>>some authenticate by means of a password or other authenticators, >>>others have a certificate for authentication. > The servlet spec gets in the way of some of your ideas here. It > essentially mandates one and only one mechanism for authenticating > users per webapp. There are tricks you can play here but it gets quite > complicated very quickly. > >> I have the same opinion. That's why I suggest to use UserContext for each >> web-app. > The idea of checking multiple realms to authenticate a user should be > a lot easier. I haven't looked at it but I would expect it to be > relatively simple to implement a hybrid realm that contains an ordered > list of realms and checks each of them in turn until the user is > authenticated or it runs out of realms to authenticate against. > >> For a specific web-app, all its users' certificate might be in a special >> place. so some attribute of ssl connector >> should be attributes of UserContext. > You need to be more specific. Which attributes? Greater control > per-realm of how a client certificate is verified is certainly > possible, as is how that certificate is mapped to a user. > >> The realms in o.a.c.realm package mixed up authentication & >> authorization. I >> suggest to seperate them. >> authentication belongs to UserContext. > The realm handles these processes together because they are tightly > coupled. Separating them will add complexity. What is the > justification for this? > >> I hope my information can be a little bit helpful to you. >> [EMAIL PROTECTED] > Some of your ideas have potential but others are clear non-starters. > To make your information more useful I would suggest some detailed > research followed by the development of one or more concrete > proposals, preferably supported by patches. Keep each proposal/patch > focussed on a single issue. I would suggest that a detailed study of > the authentication and authorisations sections of the servlet spec and > the low-level workings of SSL would be good places to start your research. > > Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
