Re: [jboss-as7-dev] security APIs/SPIs really need a redesign

On 09/22/2011 04:23 PM, Bill Burke wrote: Not going to repeat, this is good stuff though. Jumping right into it... YES. Not sure about this exact implementation. There are two angles to the problem. First, there's management. I think there is a desperate need to provide a user (or generic principal) management database which can be administered via the console or other mgmt API - users added/deleted, rights granted/removed, etc. This includes the listing users requirement. Second there's the API consumer. As you point out, many authentication schemes require this kind of first-class access to the authentication database. Anything challenge-response, for example; this includes anything using SASL (which in turn includes LDAP servers and Remoting, not to mention most modern TCP-based internet protocols). Images, biometrics?, other stuff like that. The catch is, these two aspects don't always overlap. It may not be possible to manage all types of user store. In particular AS might be a client for a specific authentication model (like PAM for example) without the ability to actually administer it in any way, even basic stuff like listing users. So such an API needs two aspects - one which exists to perform the bare task of authentication, and one which provides all the management goodies that the particular store implementation can make available. Some other significant factors - many authentication protocols (including Remoting's, it is turning out) are realm-based or are to the point where even the mechanism selection can depend on the realm or user name the user is attempting to authenticate to. You hinted at this problem when you mentioned traditional auth. vs. OAuth, though in the web case, I believe the user presents the desired mechanism before trying to authenticate. I recall that RADIUS authentication also falls into this category. For example, imagine a mixed user-password database where some passwords are clear and some are one-way hashed. Challenge-response password protocols generally require access to a clear password, so the authenticating server would have to find the user entry before determining whether a challenge-response authentication can proceed. I think JAAS still has a certain place - but that place has nothing to do with network authentication. It still makes sense for example to authenticate to a Subject for example - it's already fully integrated into the Java Security Architecture so it doesn't behoove anyone to try and replicate this. That said JAAS authentication should be restricted to cases where it really makes sense - where you want to authenticate as a new Principal in the context of an already-running thread on a local server (i.e. not over the network). The difficulty is that (depending on the implementation of the security store), choosing the store might depend on the requested mechanism or identity; or, choosing the mechanism might depend on the requested identity (and thus the corresponding security store)... That'd be nice. Seems doable. Can you elaborate? -- - DML