> The first question, really, is what are you trying to
> do? Do you want to create a custom authentication
> component, or do you simply want to use a JDBCRealm.
Well, ultimately I want to be able to tell my customers very straightforwardly and simply what to do when [i]they[/i] want to authenticate using their own LoginModule, and what to do when [i]they[/i] want to authorize using their own Realm implementation.
I'm trying to figure out, in the first case, whether it is still true that part of what I have to say to them is: you must extend the com.sun...GlassfishLoginModule class.
> In either case, the most straightforward tact to take
> is to simply head over to FishEye and pull up the
> JDBCRealm implementation, as it's been bundled within
> Glassfish for sometime.
OK, and I should take its design as prescriptive? That is, if it extends X, then I should tell my customers, "You must extend X"?
> You can tweak or create your own realm using
> JDBCRealm as a template/prototype. And when you're
> done, plop the class in the $domain/ext/lib
> directory, restart it, and reference your realm
> directly from the Realm page in the appserver (just
> like you reference JDBCRealm or LDAPRealm).
Excellent; OK.
> If you simply want to use JDBCRealm, then it works
> pretty much like any other realm, but, again, the
> source to the implementation is a viable reference to
> how to use it.
OK.
> If you want to use something LIKE JDBCRealm, but your
> table structure doesn't necessarily work as is, you
> can typically make SQL Views that mimic the structure
> that JDBCRealm uses, and work with JDBCRealm out of
> the box.
That's a good point; I hadn't thought of that.
> If you are wanting to create a completely custom
> authentication mode, you basically can either
> implement a Realm (which is a GF specific artifact),
> or you can go the JAAS path using a login module. As
> you noted, in GF, the login module is also GF
> specific (as it subclasses an internal class).
>
> In truth the work is pretty much the same. I would
> simply go with a Realm, solely because you can easily
> take the source code from the Realms provided in GF
> already and pound on them readily to get a working
> example, without having to go through the JAAS
> configuration process. It's simply easier to use a
> custom Realm than a custom LoginModule. It's not
> portable, but it's easier.
OK. I have one customer in mind who already has a (fairly significant and standards-compliant) LoginModule that interfaces with a truly nasty and hideous authentication component. That LoginModule does not extend any Glassfish code. Is it a requirement above and beyond the usual contracts for LoginModules that [i]their[/i] LoginModule must nevertheless somehow (wrapping, delegation) extend a Glassfish abstract LoginModule? That's what the documentation led me to believe. I find that a little weird, if so.
> If you truly need portability, go with a LoginModule,
> and pull your code out in to a separate class, and
> then use the GF specific LoginModule class as a
> wrapper to your real code. Then when you port to a
> different container that uses a "regular"
> LoginModule, your porting effort will be simpler.
Thanks for your input.
Best,
Laird
[Message sent by forum member 'ljnelson' (ljnelson)]
http://forums.java.net/jive/thread.jspa?messageID=215979