User Authentication

Networking & Multiplayer
#1

I have read the tutorial provided by the latest release of SGS, but i couldn’t find any guidelines related for defining a custom authenticator. However, there is a line in the client tutorial indicating that there may be a authenticator writing manual.

on page 6:
Writing and using custom authenticators will be covered in the SGS Stack Extension Manual.

Can anyone tell me where can i download that manual, please?
Can anyone guide me how to write a custom authenticator, please?
Thanks in advance.

#2

I’m writing it right now. Ergo the tense of the sentence :wink:

Its due for release at JavaOne in about 7 weeks to coincide with the Open Source release.

In the meantime if there are specific questions I can answer pls feel free to ask.

(“How do i write an authenticator” is a general question, not a specific one :wink: )

JK

#3

Hi

This is all undocumented so far, but the interface you want to implement for custom authentication is com.sun.sgs.auth.IdentityAuthenticator, you’ll need to add your implementation class to your application properties file. e.g.

com.sun.sgs.app.authenticators=com.sun.sgs.impl.auth.NamePasswordAuthenticator

That will give you the password file implementation that comes with SGS. You can use com.sun.sgs.impl.auth.PasswordFileEditor to create a password file. The file needs to go in your data dir for your application and be called passwords. I suspect there is a property to be able to change that, but i’ve not worried enough to look :slight_smile:

HTH

Endolf

edit: com.sun.sgs.impl.auth.NamePasswordAuthenticator.PasswordFile i think is the property to change the path to your password file if you wish to change it :slight_smile:

#4

Thanks for the reply, i will try to code it by following this:

com.sun.sgs.app.authenticators=com.sun.sgs.impl.auth.NamePasswordAuthenticator

#5

Curse you red baron!

;D

Seriously though, good detective work. Just keep in mind that details we haven’t published yet are free to change until we do.

Now… can you find the hidden profiling code? :wink:

#6

Aaaah, thats what the profile package is about, I saw it and wondered what it was :slight_smile:

You got me interested now :stuck_out_tongue:

Endolf

#7

Its very early, there is still a LOT we intend to add to it. Still, if you can figure out how to turn it on it could be useful :wink:

#8

You had to go and throw the gauntlet down didn’t you ;p

Hmm, that ones proving to be a little trickier :). Looking in the debugger in eclipse it appears as though the profile data manager etc are already installed, so it’s not as simple as changing the property that sets the implementations of those. Hmm, the MasterTaskConsumer has an attribute of ProfileCollector that isn’t set, so I think I need to look at that :), I’m also waiting for something to open on port 43005 as listed in the AggregateProfileOpListener :slight_smile:

Endolf goes to check what the licence said about decompiling the code :wink:

edit
No need, Kernel contains com.sun.sgs.impl.kernel.Kernel.profile.level, time to find out what values it takes and what it does :slight_smile:

#9

Your going to regret having thrown down the gauntlet :slight_smile:

I figured through trial and error that the property goes in the sgs-config.properties, and that it’s valid values are on or off (anything else gives you a warning message), when it’s on I get 2 extra ports being listened to, 43005 and 43007, I made a wild guess and pointed a browser at the ports :slight_smile:

TaskCounts: TotalTasks=205 AvgLength=108.70731707317073ms Transactional=89 AvgLength=249.6067415730337 Successful=205 AvgLength=108.70731707317073ms AvgStartDelay=14.575609756097561ms AvgRetries=1.0 AvgOpCountOnSuccess=108.14634146341463 AvgOpCountOnFailure=0.0 OpCounts: createReference=206/206 getBinding=254/254 setBinding=8/8 removeBinding=2/2 nextBoundName=2/2 removeObject=1/1 markForUpdate=2621/2621 createObject=210/210 getObject=16022/16022 getObjectForUpdate=1/1 setObject=2841/2841 scheduleTask=0/0 scheduleDelayedTask=0/0 schedulePeriodicTask=1/1 scheduleNonDurableTask=1/1 scheduleNonDurableTaskDelayed=0/0 scheduleNonDurableTaskPrioritized=0/0

Second port gives

Snapshot[period=10000ms]: Threads=4 Tasks=6/6 AverageQueueSize=0.16666666666666666 tasks

I’ve done the leg work to get it turned on, I’ll let others figure out what it all means, although anyone who understands how to use the server API should be able to make some educated guesses :slight_smile:

QED ;p

Endolf

#10

Jeff,

I’ve created my own custom authenticator by deriving from IdentityAuthenticator. I had a security question, when the NamePasswordCredentials object gets passed to the server, is the transmission of that password encrypted in any way?

#11

No there is no encryption. It is sent in clear text across the wire.

I was attempting to write a challenge/auth system kinda like S/Key or Digest Auth in HTTP… Seems that to accomplish that not only would I have to write a custom Authenticator but also a replacement for SimpleClient as simple client has no means to pass the challenge to the client.

Why they got rid of the JAAS Callback approach is beyond me. I guess they wanted it to be simple for 90% of the users.

#12

Well even if they don’t provide a secure transport for passwords, I don’t see that it would be much of an issue of writing my own. One simple way of doing it would be to simply allow the client to connect to the server under all circumstances, then after the connection is established build your own authentication protocol after the fact.

#13

Yep! Of course if all you wanted to do was encrypt the data you could do that with an Authenticator Impl. On the client you would simply need to encrypt the password before setting it on the PasswordAuthentication object… Of course you would have to encode the encrypted password as a series of characters… (aka Base64 or something like that)…

Or they could simply return to the JAAS Callback methodology and make the Container useful and extensible? (Aka if we are going to write everything ourselves where do we want to stop?)

#14

I litterally started looking at Darkstar yesterday, what is the JAAS Callback methodology?

#15

Lots of things changed since the last public release. In the previous release they had a TCP client. When the connection was established with the server the server would iterate a list of Validators (kinda like JAAS Login Modules). Each Validator had the ability to send a collection of Callback handlers from the server over the wire to the client. Each time this occured a handleAuth(Callback[] callbacks) method was called on the ClientListener.

Aka the JAAS Callback methodology. In this case I could implement a Callback called Challenge which included a random string and a numeric. Thus when I got the password from the user I could hash it with the random string numeric number of times before setting it on the PasswordCallback. And all of that could be returned to the server and parsed without concern of the type of transport.

In the current release they have simplified (over simplified in my estimation) the communications stack with this SimpleClient. Now rather than the server challenging the client at all the protocol (aka SimpleClient) defines a getPasswordAuthentication() and it calls it and sends it to the server during connection irrespective of whether or not the server even cares. Obviously PasswordAuthentication only accepts username/password. So it is impossible to implement any sort of SmartCard, DigitalCert, DigestAuth, or any type of Auth mechanism other than username/password. Likewise, since it is part of the protocol (hardcoded) rather than an abstract pattern you must replace the SimpleClient with a REAL client to do anything different.

But the biggest hassel of this methodology is that you MUST implement some sort of userid/password even if the server doesn’t even care? Aka if you plan on using NullAuthenticator which is the default by the way on the current release…

To me it makes more sense to impl the JAAS Callback methodology in a generic fashion and then have them provide a simple and null implementation for those 90% of users but provide the other 10% with the ability to quickly implement something stronger without having to write our own client/server transport and or apply layering to our application as you suggested.

By the way there may be an issue with your idea of implementing the auth system after connection. When the connection occurs the ClientSession is created by the server… (aka out of your control). To construct this object it needs a name. That name is the userid of the user. What happens when the server has two ClientSession objects with the same USERID (aka Name)?? I’m not sure but I doubt it could be good. And without authenticating prior to creating this object you open up a potential security vulnerability.

#16

Duplicate user id’s are easy to detect, and you just have to return null from the AppListener loggedIn method, I already do that.

Being the Sun Game Server I suspect that they figured that most of us would be using username/password type authentication, and anyone using anything more complicated was in the minority, but could do it be extending simple client and the authentication implementation in the server. IIRC Jeff has said the docs to cover the stack extension are due out the same time the stack goes open source, which is due for Java One.

What is currently shipping is a restricted distribution binary, so you can’t publish anything with it anyway yet, which makes security not an imediate concern. I’m sure somewhere down the line someone will wonder why the whole comms layer is not encrypted in some way, IIRC (no, I don’t have any references, but its something I remember reading) a large number of modern games encrypt all the wire traffic anyway to stop people inspecting and manipulating the protocol. Again, I suspect that the stack can be extended to include this functionality.

Endolf

#17

I realize that they are playing the numbers game. But there is more. The concept of JAAS is very Java specific. They are also planning on an API that will work with various client languages such as C and I am sure others… And JAAS Callbacks are inherintly Java most especially when you start talking about custom callbacks. I mean how would you send Callbacks in language neutral way? You would have to define the Callbacks as messages of some sort. Thus eliminating the ability to create custom ones.

And I realize that language nuetrality is a core objective and an important one. It would be possible to define the API to support it. Even if they had to have the Authenticator implementation do the encoding/decoding of the messages being transfered between the server and the client… Aka how to encode/decode custom callbacks? Let the implementation do it!

And your right in the long run I am sure they will include support for SSL. Which could be an alternative.

#18

Pretty much. We figured for development the most you’d want is simple username/password. For release we figured you’ld want to plug it into your own authentication and user management. system which would be custom and specific to each installation.

The EA stack actually used the JAAS mechanism and, honestly, we found it over-complicated the issue without a lot of benefit. The “password” passed back to the system is actually a byte buffer and can contain any data your authenticator wants, including serialized JAAS callbacks if thats how you want to do things.

Yes indeedy.

This is why the transport protocol is ALSO pluggable 8)
Games tend to all have their own, often hidden, schemes for packet security.

#19

Hey folks. As the guy responsible for the profiling and authentication systems, I wanted to chime in with a few clarifications…

On Authentication: The discussion thus far has been pretty good. One thing to understand is that there is no assumption that name and password pairs is what must be used. This is an artifact of the initial Protocol being used, which only supports challenging clients for a name and passphrase. The Client API that is currently available is designed to work with this simple protocol. Likewise, the Authentication modules written thus far for the server support the protocol. When the code is released, you’ll be able to plugin new protocol handling, which will also let you define any authentication scheme you wish. As folks have already discovered, the authentication system on the server is pluggable; if anyone has specific questions about how to use this, feel free to ping me.

On Security of Credentials: Related to how users are authenticated, and how credentials are expressed, is how the process is secured. The “easy” and standard way to protect this process is either to use TLS to protect the communications, or to use a one-time scheme; both of these have been discussed here already. Again, when you see how to plugin protocols, you’ll also see how to support these schemes. Rest assured that the current model is designed with all of this in my mind. If you google for some of the security-related work I’ve done, you’ll see that I have a passion for this stuff :slight_smile:

On Profiling: Yeah, those numbers are somewhat dense, huh? Here’s the short version. We have a basic profiling system in the current stack that lets us monitor what’s going on. Over the next several weeks we’ll be adding a number of features, but currently you can observe stats about tasks, retries, queue-length, operations within a task, etc. There’s also a generic listener interface for consuming these statistics and formatting them. The two that output on ports 43005 and 43007 are examples that we’ve been using to watch some basic aspects of the system internals. Again, if anyone wants more detail about these, feel free to ask. Pretty soon we’ll be releasing all the details about how this works, and you’ll be able to write your own modules to observe, aggregate, and correlate what’s happening. On the whole, I think it’s pretty cool how much data you can extract about the state of the system.

Hope this helps…

seth

#20

It sounds to me that you will be able to do this via jnag.
Just ignore the login and password, leave it empty, and accept the connection. Then, use jnag to do pass the callbacks from the server to the client and use it on the client to answer the challenges via the passed callbacks.

I will probably publish a new version of Jnag in a few days on CVS.