Wow, I'm impressed. Two o'clock on a Friday afternoon, so many people. How's everybody doing? "Grab the week's almost over." So we're going to talk a little bit about network authentication. I'm actually quite surprised at the number of people that are interested in that. What

Eric Clement: Okay, well this is a hands-on session, we're going to be going over a little bit of code as part of this, but I'm going to do a little bit of discussion about where we're going and what we're trying to do.

So let's get right into this. My name is Eric Clement, I'm a directory services engineer. I work on our Open Directory and Active Directory plugins. So, what are you going to learn here? Well, we're going to talk a little bit about Open Directory, where we're going with authentication, do a little bit of discussion about authentication in general, what that means, things like Kerberos, single pass--clear text passwords, challenge response passwords, give you a little bit of code examples after that, and then go into a Q&A.

So, how does Directory Services work? Directory Services is actually an API, but reality is it talks to a back-end daemon. Most of you have seen this daemon called Directory Services. These APIs do nothing on the client for the most part. All they do is send a call across the Mach message over to the daemon and let the daemon do all the work.

This is why you only have one API and a smaller framework footprint on your client. Eric Clement So, the great thing here is, in the future we can do a lot more in Directory Services, and who knows where we can go there, but, you know, maybe... caching in the future.

Typically, most clients would actually write that into their client. Well, you wouldn't have to do that if we implemented something in directory services. So that's just something to keep in mind, possibilities of what we can do. Now, we try to point out here the user application runs in user space, and directory service statement actually runs in the system space. Now that allows us to talk to anything we want. We get files on the system. That's how NetInfo works, etc.

So where are we going with authentication? We support all the legacy protocols today in Open Directory. That includes ClearText, NTLM, NTLM v2 now has been added, and all the various protocols, CRM MD5. Now keep in mind, this doesn't mean that every system will support it. Just because the directory service supports CRM MD5 doesn't mean the particular directory you're talking to will support CRM MD5. So things to keep in mind if you decide to write an application that uses the directory service APIs, and to pay attention to those error codes you get back from the APIs.

We've said this for the past couple of years, we're very actively pursuing KerberoS. KerberoS is our solution for network authentication. You'll see that across all of our applications in Mac OS X and Mac OS X Server. We're actually authenticating the majority of our services using KerberoS. The great thing about that is, entering the passwords and usernames, you don't have to do that anymore. It's a single sign-on technology. I'll talk a little bit more about that in detail a little bit later.

Panther, Tiger, Server, both we added all this functionality quite some time ago. And the great thing is, a lot of the customers, hopefully a lot of the IT folks here are doing it, are deploying Mac OS X Tiger and Panther in your environment. So the great thing is if you're deploying OpenLDAP or Open Directory on your system, you get the advantage of all these various protocols, all these various authentication methods built in right out of the box. So if you have a particular web application and you want to use CRAMMD5, for example, you can use CRAMMD5 and it'll work. Or maybe you wanna use some other method. So that's one of the great things about deploying Mac OS X and Open Directory in your environment.

We've tried to remove as much as we can to make this difficult. So obviously we've got all the APIs and what you're going to see here today is we're going to give you some sample code to go back with you that will actually make it a little bit easier for those one-offs. You know, I've got a web application I want, I want to do a quick authentication, all I've got is a username and a password, let me authenticate that.

So we're trying to make that a little bit easier for you, just some sample code to take back with you. This is just a starting point, it's not everything you may need to do, so keep that in mind. Also keep in mind, as I said, these APIs work across all the directory systems, so things you may want to do with LDAP, guess what, it works with Active Directory.

So how do you authenticate a user? Well, the reality is we're kind of focusing here on the back end. I've got a web application. I've got a new application I'm bringing up that has a client server base. We're going to focus on the back end of that, because the reality is, typically if I was a GUI on the desktop, I would use Security Framework, I may use PAM or some other authentication service. But on the back end, the reality is, you'd want to use directory services for all your authentication. The reason is, just like I said before, you want to get to those other directories.

Server-based applications, we definitely recommend either PAM, although we actually recommend Director Service first, because Director Service will do all the things that you would ever want to do, we hope. GSS API is our recommended method for doing your authentications. GSS API is obviously used within Espinago for web applications. So GSS API is your single sign-on Kerbero soft. It's a token that gets passed around for all your network authentications.

Who knows the difference between authentication and authorization? I didn't quite see enough hands there. So, you know, this is always a point of contention for some people that they think they're actually the same thing. Well, they're not. Authentication is proving who you are. I'm Eric Clements, I can prove it.

I've got an ID. Does that mean I have access to go run into the other room? Or I have access to, you know, take somebody's car? No. So, you know, proof of identity is just one step within authentication. The next step is to authorize a person. So in Mac OS X Tiger, we introduced ACLs.

ACLs are part of your authorization mechanism to say who has access to run this application, who has access to use this application. So that's a very distinct difference. And you'll see through some charts I'll show in a second that just because you authenticated somebody, somebody doesn't mean that they have the access to actually use it.

We typically use groups today in most of our membership checks. You may have something else. It could be a flat file, it could be a database, it could be anything on the back end that you use to prove that that user has access to what you're trying to get to.

We obviously support service ACLs. This is what's done with what we call our Member D process. We have a published API to say, "Check for this service and see if this user has access to that." We're not going to demonstrate that here, but keep that in mind. If you want to go down the path of saying, "Does this user have access?" Use those APIs.

So everything that we have is included in our Open Directory Framework, also known as Directory Services Framework. All you have to do is include one header, and with that you get all the APIs you need to do anything with all the various directories. The one we're going to talk about in particular is DS-DudernodeAuth.

And when everybody looks at these APIs, they give me kind of a hard time about them. But actually, the great thing about this is, we've been able to extend this protocol, or this API, to support all these various methods that we've been adding over the years. We didn't support NTL in V2 and Panther.

Now we do, and it's all with the same API. So it's one of the great things about this. And with the code samples we're going to give you, we'll hide some of this from you, so you don't have to worry about it. But the great thing is, you can use all these various authentication methods.

So Kerbero, I talked a little bit about GSS API and Kerbero. Kerbero is a ticket-based authentication. Once I get authenticated, I get a ticket. That ticket proves who I am and allows me to get tickets to get to other services. Now this has been widely adopted by us, Microsoft, even Novell's gone down this path and several others. A lot of you have been playing in the Kerberoos world long before we entered this space. But it's great technology, we're really excited about it, and it's really become an industry standard across the board for single sign-on.

You know, single sign-on has always been the holy grail. You know, sign into the desktop and just launch and get to all my applications. How many of you had 10 passwords or more and wrote them down? That was always a nightmare. The great thing is here you don't have to worry about that anymore. And the great thing is, you know, Kerberos has a whole lot of functionality.

It supports encryption, packet signing, mutual authentication, all kinds of the buzzwords that are very important in your environment because as we continue to go forward in this space, people are more concerned about not just proving who the user is but also ensuring that I'm talking to the server that I think I am. You know, we sometimes forget about that. You know, you walk into a Starbucks and I connect to a server and say, well, it must be www.apple.com. It says it is.

So it must be it, right? So the great thing is, with Kerbero, we get down to this path and say, "Now I want you to prove that you are the server I think you are." So this is one of the great things about Kerbero, and we're really excited about it in general. Now we do recommend GSS as the kind of starting point. I know some people do some things directly with Kerbero.

GSS has become the most common method of doing Kerbero authentication and tickets. In reality, the SPNago is actually a Kerbero, a GSS token inside of the encapsulated packet. And I also recommend, you know, some people try to do things manually and say, you know, I'll figure out how to negotiate my protocol. I really recommend looking at using things like Sassl.

"Use the open standards, find ways to authenticate a user, find ways to negotiate that user's authentication with those open standards. Because it will make your life a lot easier, allow you to expand in the future to other things. Because down the road, maybe there's something beyond Kerbero's." So keep that in mind and try to use the things that are already in place that are very common in this space.

So things you need to really be concerned about though, if you go down the Kerbero's path, you really need to think about your IP address. So one of the most common problems we have is people have servers that have forward lookup entries but don't have a reverse entry.

So I know I'm going to www.apple.com, but if I looked at that IP address, it says it's nobody. Well the problem is in a Kerbero space, that doesn't work. We actually expect to be able to look up that host name because that's how you can get the information in order to get the tickets you need.

So even in Mac OS X, you'll notice in Tiger, when you configure your server now, the host name is actually derived from the IP address that it's getting. So we're trying to do our best effort to make it easy on you, but keep in mind if you go down the Kerbero space, you really need to keep your addresses forward and reverse matching.

The other thing is, in our space we actually use a single key tab. That key tab is controlled by root access. So if you're gonna run on our platform and use existing keys, keep in mind that if you're writing an application, you may need to have that application running as root.

Typically that's not always the smart thing to do, but we've tried to work around some of that and we recommend you need to look at that if you're gonna use Kerberos and the key tab built in on a host.

The other thing to keep in mind is, as we've seen this ourselves, that service case is very important.

Not every protocol is alike. So look at the specs, look at what you should be using, and be sure you're using the right service type. Because the reality is, Kerbero is case sensitive. So if I have a service key for, in this case, HTTP, "It's actually uppercase. And if you ask for a lowercase version of it, you're not going to get it, because the KDC doesn't have that. So just something to keep in mind from Kerbero's perspective.

Let's talk a little bit about the flow of authentication. So this is just two of the examples out of the three that we're going to do in the code. The first one being the password authentication. So what's the first thing that happens? You get a name and password.

So what's different on the platform here is in most cases you take whatever username you got and do an authentication. Well, on Mac OS X, we have the concept of multiple usernames. So when I sign in on my computer, I sign in as Eric Clements. Our reality is my username is really E.Clements, but I don't use that name half the time, right? So you really need to look up the user and find out what username to authenticate as.

This is very important because as protocols vary and in fact you see this AFP, we will authenticate against AFP with a long "Or the short name, we don't really care. Some other systems don't do that. So you need to find the official record name of the user and do the authentication with that record name. And you do that using DS-DurrNodeAuth.

And then the most important step I mentioned before, check the authorization. Now in your case you may not care about the authorization. Every user that authenticates has access, so that may not be pertinent in your case, but if you put the step in there and have it there in case you decide to use it, then you've already got the functionality. And then at that point is when you decide to allow or deny that access.

In the Kerbero space, it's slightly different. You actually get a service ticket that you're going to verify. So once GSS and Kerbero has verified that service ticket, then the next thing you're going to do is look up to see if the user is a real user. Now that's important because just because I'm configured for Kerbero doesn't mean I'm pointed at a directory that have users that can log in.

If you take that user just because they're in Kerbero, doesn't mean that they're a valid user on that system. So one of the other things that we do now is you actually need to look up that same user in the directory and say, "Is this a user in this system?" Then you also check to see if they're in the authentication or authorization tab. Then at that point you allow or deny the access. Obviously in a password challenge it's slightly different, but it's a very similar concept.

So let's jump right over to code example and some demos. So this is actually published on the web. So if you want to pull it up, you can take a look at it. I've got a couple sample applications and code. I'll kind of step through here. We've got three applications called Lookup User, Demo Server, and Demo Client. The concept here was I was going to have a demo server running in the background, and I'm going to have a client and try various authentications against that server and see the fact that I can deny it or prove it.

So I tried to document at the top of these some key steps that are going on, just like you saw before. In this case, we're going to look at the Lookup User. What does it take to look up a user on Mac OS X? Well, there's actually a lot of APIs from a DS perspective, but I tried to make this a lot easier.

So you'll see these APIs actually documented in these headers. These are the common code that you can take, use it, modify it, however you want for your applications. And lots of header docking here, talking about the various functions, including locating your search end. So the first thing is we have the concept of an authentication chain.

That authentication chain determines where users should be able to authenticate to the system. So the first thing you do is find that authentication chain, and that is your search node. Next, we locate the user and do an auth. So let's just actually just jump back to this lookup user and see what the code's like. So first thing we do is we have to open up directory services. You'll see this on this first dsopendir service. Once that's valid, we can go get our search node. Then we can look up the user.

And here basically, once we've gone past that point, we have found a valid user. So let's just actually do this. So that's a quick output of that. You can actually see the fact that "demo auth" is actually "demo auth" lowercase all concatenated together. And it actually tells me where that user is located.

The reality is if this was an Active Directory, for example, it would say "Active Directory" and some domain off of that. Or if this was an Open Directory, it would say "l.v3" and some IP address or some node name. So it's very important to this step. This is just the precursor to actually doing the authentication.

Is that better? So next we actually have the demo server. And this is the core of the code that you would need to do if you were doing an authentication on the back end. This is your server application and you're gonna verify that user and take their authorization with that code. The demo client that is provided here we're not really gonna go over because this is just getting as an example of how to send the credentials across the wire. This is not production code. Please don't use network routines. These were just thrown together for the demonstration.

So in this demo server, we've got three different authentications. First, we've got a clear text. So this is what I said, you know, we have a ClearText password, doesn't mean that you should be sending that password over the wire in ClearText. In my case I am. But please don't do that in your apps.

So, just like before, as I said on the presentation, first you need to locate the user. First we need to look at the user and the directory. Then we're going to get their official record name. This is that step where we turn demo auth into demo user, or demo auth concatenated. Then we're going to authenticate them with the appropriate authentication type. And the key difference here, we went up to this point, but now you'll notice here we're going to actually do the authentication.

So let's just jump over and just run this real quick so you can see it. So in this case, you can see I'm running my application here called Demo Server on port 2500. I did throw out a little warning here because we're not actually going to do a Kerberoos demonstration in this case. But if I was doing a Kerberoos, I'd need to run this as root. So we're going to do a clear text auth on port 2500 with this machine, with the user demo auth and password Apple.

You notice that the server accepted the credentials and notice I actually logged on the server side that we've received a clear text authentication and that it was a successful auth. Now let's just do that again, but let's mess it up. Now you notice I've actually said it was rejected.

And you notice on the back end, it says it was an invalid authentication. It's very easy to do, and all these functions are located in these DS Utility files. Now, you could simplify this into a smaller routine if you like. Maybe all you care about is one Auth, and then you can close down Direct Services and I'll do it again later. We tried to make this a little more flexible, because you might be doing multiple Auths at the same time. So we left a little flexibility on what you might want to do.

Now let's jump down to the CRAM MD5. So CRAM MD5 is a little different, because this is a challenge response. In this case, the server is going to send me a challenge, and I'm going to craft a response based on that challenge. Because I don't want to send my password in some way that somebody could figure out what my password is. So I'm going to take that challenge, do some operation on it, in this case a CRAM MD5, and send that response back to the server.

Now, just like you saw in the previous code, all the same steps. Open the search node, locate the user, I've got a user, open the node. In this case, we're going to do a challenge response. So in that challenge response, we'll just kind of look at that real quick because it's slightly different.

You notice the parameters, we actually expect the challenge. And that challenge can be of any length depending on the protocol. In this case, we follow the standard RFC for doing a CRM MD5. You notice here, this code is very generic, because the goal was that you have one function call to say, "I'm sending CRM MD5, I'm sending APOP, CHAP, LM, NT hashes." So, one function routine that you can call.

Now in our case, We're going to do a quick demo. We're going to switch the protocol to CRAM-MB5. And you'll notice a slight difference on the server this time. We generated a challenge when the connection came in. "And the client responded to that challenge. In this case, it was still a valid authentication." Now you'll notice that in the sample code that you've got, a little bit higher in here, if you go to handle CRM NB5, you'll notice that we're generating a challenge.

This is all based off of RFC 1460. Sending tokens, reading tokens back, and doing the authentication. So I tried to master this a little bit for you. Like I said, this is a good starting point if you need to do any of these authentications. Next, we've got a GSS API, which is slightly different because GSS API, one thing to keep in mind is, depending on the options the user selects for the authentication, you may have multiple round trips.

In challenge response, you've got a challenge and a response. GSS API, you may say, I want mutual authentication, I want encryption, I want packet signing, etc. You may have multiple steps going back and forth between the client and server to negotiate all that information. So that's something to keep in mind. And you'll notice in the code here, when I'm doing this auth, I'm actually in a loop.

"I put a little documentation dumping out things here, but you notice I would receive a token, I do the auth, if I have to continue, I keep on going until I get a final result." As I said, I'm not going to demonstrate the GSS because that does require all of our DNS and everything set up and we don't have that here today. So that's basically it. It's not super complicated. Our goal was to give you something to start with, to look at, and to keep in mind, and what we think you should be doing.

Back to slides, please. All that make sense? For those that are coders? For more information, obviously the website for the conference has all this sample code on it, as well as SDKs for directory services and other APIs. Who you should contact? Obviously Skip Levens is our contact for WWDR.