Keep in mind that if you liked the old JAAS system there is no reason you couldn’t write it as a plug-in authenticator.
One thing that might be worth asking is if the Idenitity object can be made available through the ClientSession. Currently it seems like it is little different from a Principal object. (aka nothing but a name)… It would be nice for Authenticator impls to attach Permissions or Credentials or some other properties on an implementation by implementation basis. Of course all of that would be worthless if the application couldn’t get reference to them because they were shielded by the ClientSession object.
I would propose that the ClientSession API include a
public Identity getIdentity()
or
public Identity[] getIdentities();
method so that the Authenticator could implement any type of Identity it wanted and include any type of property with the Identity impl and finally the application could actually use them…
Of course you could leave the Identity interface opaque requiring application specific casting or it might look something like:
public String getName()
public PermissionCollection getPermissions()
public String getProperty(String key)
Anyway, just a thought…
Actually, there’s something similar to what you’re proposing in the current model. While an Application can’t get access to the Identity object, a Manager can. So, what you can do is write a new Manager (and Service) that provides exactly the kind of methods that you’re talking about. The Identity interface is opaque, and indeed authenticators do get to implement any type of Identity, and therefore include any type of properties that they like. The idea is that with these different Identity implementations you could expose different features through different Managers. I know that the Manager/Service extension API isn’t clear right now, but (and I know this sounds familiar) when the code is published this will be clear. In fact, Jeff is working on a great guide to walk you through exactly this process.
In the meantime, folks should let me know if they want to prototype something like this now, and I’ll get you started on the right path. Also, don’t be surprised if we release some examples in the future that do exactly the kind of thing you’re suggesting 
seth
Thats good news… Thanks…
For those that just can’t wait for the server extension docs to come out (that includes me), I put up a little tutorial on creating a custom authenticator that uses a database.
http://www.darkstarusers.com/tutorials/2007/03/26/creating-a-custom-identityauthenticator
I may have created an entire site dedicated to Project Darkstar in the process. Who knows. I should have some more interesting stuff up in a few days.
I see that the client framework is setup for handling the PasswordAuthentication callback, but I don’t see anything on the server side for processing the provided credentials. Is this going to be forthcoming in the next release?
Reference SimpleClientListener::getPasswordAuthentication()
Not sure i get this at all.
If your referring to the user/password callback in the current client API, you can respond with whatever you’ld like, including just an empty string if you arent using the password. You could even put a block of serialized JAAS callbacks in there is thats your druthers. At the moment though the protocol does not support the requesting of those JAAS callbacks. If you wish to do that, you need to implement your own transport protocol, which is also pluggable.
“SimpleClient” is a front end designed for the simple name/password authenticators we have right now and the protocol they use.
We haven’t exposed pluggability on that level yet on the client side because we are still figuring out the right way to do that, but it will be part and parcel with releasing pluggable transports.
This is handled by the authenticator right now. We ship with two right now, a default NullAuthenticator and an encrypted file based password authenticator.
Custom authenticators are going to be fully documented in the coming SGS Extension Manual to be released at Java One. Til then you can get a peek at some info the community has figured out here:
http://www.darkstarusers.com/tutorials/2007/03/26/creating-a-custom-identityauthenticator
If I wanted to pass more than just username and password from an SGS client to an SGS server during authentication, for example to include an Integer representing site_id, what would I need to do? ???
Without resorting to anything fancy, you could easily squirrel this information away in the username or password fields. As you can see from the database auth example I posted. you can override the authenticator in the server side and you have complete control over what happens there.
To do fancier things you would:
(a) Override the authenticator with your own authenticator
(b) Create your own sub class of identity
© Create a custom service to read that sub class and return information from it.
All this is explained more in the extension manual. AMMTB it will be out with the GPLd release.
Currently, SGS client can only request authentication using and , and its authentication responce is a boolean responce of either loggedIn or loginFail.
I want to expand the authentication functionality.
From my understanding, the following flow graph is a crude representation of a SGS login authentication… :-\
SGS client…Requesting Authentication
SimpleClient::login()
implemented PasswordAuthentication SimpleClientListener::getPasswordAuthentication()
with responce of java.net.PasswordAuthentication with credentials data <username, password>
SGS server…Processing Authentication
implemented Identity IdentityAuthenticator::authenticateIdentity( IdentityCredentials )
with request of com.sun.sgs.auth.IdentityCredentials id,
which is implemented NamePasswordCredentials with credentials data <username, password>
with response from this method is com.sun.sgs.auth.Identity,
which is implemented com.sun.sgs.impl.auth.IdentityImpl with
SGS client…Getting Authentication
implemented boolean SimpleClientListener::loggedIn()
OR
implemented SimpleClientListener::loginFailed(String reason)
+++++++++++++++++++++++++++++++++++++
What I want to do is the following… ;D
SGS client…Authentication request
SimpleClient::login()
implemented IdentityCredentials SimpleClientListener::getIdentityCredentials()
with responce of implemented CustomIdentityCredentialsImpl with credentials data <x, y, z, ...>
SGS server…Processing Authentication
implemented Identity IdentityAuthenticator::authenticateIdentity( IdentityCredentials )
with request of com.sun.sgs.auth.IdentityCredentials id,
which is implemented CustomIdentityCredentialsImpl with credentials data <x, y, z, …>
with response from this method is com.sun.sgs.auth.Identity,
which is implemented CustomIdentityImpl with data <a, b, c, …>
SGS client…Authentication response
implemented boolean SimpleClientListener::loggedIn(com.sun.sgs.auth.Identity)
which is Identity instance of CustomIdentityImpl with data <a, b, c, …>
OR
implemented SimpleClientListener::loginFailed(String reason)
Thanks
In about 4 weeks the stack extension manual will be out and all we be clear grasshopper.
Sorry, but I am writing the manual for a reason. All that you want to do is doable, but I really don’t have the bandwidth to be re-writing the manual in forum posts. Wait til it comes out. read it, and then fire any remaining questions at me.
Whats the rendezvous for the manual?
I believe Jeff has said that the documents are set to be released to coincide with the release of the SDK soon after the Java One conference. I think that is next week.
Yes, thats correct. The manual will go out with the open source release. Unitl that time some of thsi is in enough flux that we don’t want to mislead you.
I don’t have a clear ETA on the open source release yet except that we won’t make JavaOne as we had originally hoped. I apologize profusely for that but the team wants to make sure what they drop on you is really reasonably complete.
Til then, for design considerations:
There are basically two issues here , though you can eliminate one of them with a pit of pain.
The first issue is that you need to write a custom authenticator. thats actually not so hard. if you want a peek at how to do that ahead of time, there is a good thread I’ve referenced in the FAQ plus BunnyHunters which will be released for JavaOne contains an actual example.
The second is the issue of getting your multiple parameters up to the authenticator. You have two chocies here
-
The more work, technically proper solution. Implement a custom protocol and your own client side API extension around it.
-
The sneeky quick and dirty method: pack them all into a char array and use the existing API and protocol
is the “out of the box” api for base level username/pass authentication out or coming with your stuff after JavaOne? Just want to mimic what kevglass did in tank, which is what I do now in CubeWars (sgs2).
Base hashed password support is in the SDK. You need to enable it though.
See the thread mentioned.