Good morning. Today we're going to be talking about, in this session, something new in Leopard that we call Identity Services. I was just yawning before I came out. I have to point out that if you're going to have to give a big talk in the morning sometime, I personally recommend if you want to look and feel your best, you go to a big party the night before with lots of really loud music that shakes your whole body and drink a bunch of beer. That works for me pretty well anyway.

So with that in mind, let's get started. I thought that I would structure this talk around some actual software, some sample code that we want to add some features to. And so I'm going to start with kind of an overview of where we are in Tiger with peer-to-peer networking between Tiger systems and look at a sample app called Picture Sharing, which is a software that we've been using for a long time.

And then we're going to talk about some of the features that we've been using for the developer tools, and then talk a little bit about Identity Services, and then integrate that into Picture Sharing so that at the end we have a better Picture Sharing. And we'll see what it does. Thank you.

So when I say peer-to-peer collaboration in this session, what we're talking about is connecting between, say, a Tiger system to a Tiger system or Mac OS to Mac OS. Examples are personal file sharing, screen sharing for system services, but also applications such as iTunes music sharing or iPhoto album sharing. And maybe your application does some similar resource sharing, which would hopefully be why you're here.

The key thing about this kind of collaboration is that we want to make sure it always works well in ad hoc networks. And to that end, we have, in addition to CF Network APIs for doing network connections, of course we have Bonjour to support simple service browsing and discovery.

At the same time, we want to make sure that there's actual security, good authentication going on. As I mentioned, we want to make it work well both in managed networks as well as ad hoc networks.

And, of course, we want to maintain a great user experience. So I mentioned we were going to use a case study. This is a screenshot of an example application called Picture Sharing. This is how it builds right now on Tiger, how it looks. Really simple functionality on the server side. You give your service a name. It's basically an example code showing Bonjour, Service Discovery.

So you give your service a name, you click the Start button, and you pick a photo or an image to share from a short list that the app makes available. On the client side, this is the client app called Picture Sharing Browser. And it shows on the left a list of picture sharing services found through Bonjour. And when you click on one, it's a really simple-- I don't even know if you can call it a protocol. It just opens a stream and downloads the image into the client so you can view it. No access controls at all.

So what do we want to do to picture sharing? There's four steps. First, we want on the server side, whoever's sharing the picture, we want to be able to let them specify who is going to be able to view the picture, basically set up an access control list. Then we need to make that access control list persist so that when you quit and restart your application, we remember who is allowed to see the picture.

When a connection request comes in, we need to authenticate the connection, see who it is, and finally, check if they're in the access control list, if they have actually-- so do the authorization step. Do they have access to the picture? So what kinds of stuff do we need to make this all work easier on Leopard and make this easy to implement? We need a bunch of infrastructure. And that's what Identity Services is.

We want to make it easy for applications to get information about users and groups, both those that are defined locally or created locally, as well as users and groups on a managed network, such as in an LDAP or an Active Directory. things accessible through Open Directory. At the user experience level, we want to beef up what we can do in system preferences, account preferences, for managing local users and groups, and also come up with some UI guidelines and some new UI elements to make it easy for apps to manage access control lists.

So first, the infrastructure part. Identity Services, it's a new foundation for working with users and groups, as I mentioned, both local users as well as managed network users. It's essentially built on top of Open Directory. So any user record or group record that's in the Open Directory-- The identity store on your system is expressed as an identity in the Identity Services API. At the same time, Open Directory is a very open schema, a very open API. It doesn't really enforce any kind of policy or uniqueness.

It's pretty hard for applications to go in and say modify a user or add members to a group. There's just a bunch of data parsing you have to do, and you have to come up with unique IDs. And so the idea of Identity Services is to enforce all of that policy, make sure we have data integrity, and make it much easier to deal with users and groups.

So here's where it fits in the framework stack. It's part of the core services framework here in the middle. As I mentioned, it's built on foundation technologies in Darwin, such as Open Directory and some other things. But it also sits below Carbon and Cocoa. So if you already have an application, you don't have to change your linkage. You already have access to everything in core services, including identity services on Leopard.

So now I'd like to talk about just the small number of concepts that you need to understand to work with Identity Services. The first is just the idea of a user identity. That's simply an identity or someone, usually representing a person, that can be authenticated some way for, say, a network connection to prove who it is.

And that authentication technique is bound to some identifiers such as the full name of a person, which is what we would usually show in the UI. And there's also some machine identifiers such as we assign a 128-bit UUID, unique ID, to each user. For legacy compatibility, every user also, of course, gets a POSIX name, which is the name with no spaces, usually all lowercase, as well as a unique UUID assigned. In addition, aliases are a way to assign alternate names to an identity. So if you want to give someone a nickname, you can do that.

Now, on Tiger, every user-- oh, sorry, there's other attributes that you can assign, some optional attributes, such as you can have image data or an image URL. We support both image URLs to files, because directory servers work that way. They have either data or a path to a file. You can also put in an email address, the primary email address for a user. Now, in addition to password credentials, the API also supports storing an X.509 certificate in the repository for the user. And we'll talk about that a little bit later also.

So here's an example. We have a user named Charles Darwin, POSIX name C Darwin. A long UUID has been assigned automatically, as well as a POSIX UID. Chuck, Charles, often went by Chuck. I don't know if you knew that. And there he is. His image data is also in there. Now, on Tiger, pretty much every user was a full login user.

So if you went to Account Preferences and created a user, you got a home directory created for that user, and they were allowed to log in at login window. In Leopard, we're introducing a new class of user called a sharing user. It's sort of a lightweight user. It's stored in the same way as a regular user in the open directory store. It's available through the Identity Services API.

But it's a minimal user with no home directory, and there's no login shell set in the user record. So if they walk up to login window, they can't actually log in. They don't have access. So the sharing user is intended for when you want to be able to create identities that you want to grant access to your photos or other resources that you're sharing. And over the network, you can create local users that are very lightweight, very quick to create.

We're also supporting groups. Group identities are simply group identities that have membership. And we look at it as mostly an advanced access control tool. Most end users aren't ever going to create a group. But for advanced users that want to do a lot of access control management, it's something you always wish for right away if you don't have it.

When you start getting a lot of local users created, you want to be able to create groups for them. Otherwise, most of the attributes of a group are the same as a user. They have a unique ID, a full name, and so on. You can even have an image or an email address for the group.

So where conceptually do Identities live? And according to the API, they live in Identity Authorities, which is a trusted repository for Identity information. And every system has a built-in local Identity Authority. And that's where all of your local users are defined. Essentially, this is a representation of what's in the local open directory user store.

If you're on a managed network, you have what's called the network authority. So that might be users defined in your LDAP server. And in the API, when you say you want to find or look up some user, you have to specify where you want to look. So you can look at the network authority or the local authority. Often you want to look at both. And in that case, you specify the default authority for identities, which is a synonym for both.

repositories. All right, so that's the conceptual overview. Let's take a quick look at the API. And I just want to give you a feel for what you can do with it. It's a C API based on the core foundation runtime. So the object types follow all of the standard naming conventions they have after creating or copying them. You need to make sure you release them with CF release and so on.

There's two types. Pretty simple API, really. Type CS Identity Ref represents either a user or a group. We decided to have one type for both because so many of the functions or methods that you call on them are identical. Almost all the attributes are the same. And since C doesn't do subclassing at all, it's just easier to have one type.

That does mean that if you really need to know whether a given identity is a user or a group, you have to get its class attribute. So you ask for the class and you get back an enum value indicating whether it's a user or a group. And then most of the API on this type is a series of attribute setters and getters and setters.

The other data type is the CS Identity Query, CS Identity Query Ref. And this is how you pull existing identities out of an identity authority. You create a query. So how does that work? Basically, when you create a query object, you point it at a particular identity authority. And that means it's only going to find identities there. And you specify some other sorts of criteria that you want to search on. And you execute it. And the result is an array of matching identities.

There are several different types of queries you can create. A simple one, you just say "all," and you point it at an authority, and you say whether you want users or groups, and it gives you everything that it finds. You can also search by name, either an exact match or a partial match. You can, if you have a specific UUID you're looking for, let's say you're working with a file system ACL. File system ACLs are all UUID-based. So you have a UUID, you want to look up that user information, you create this kind of query.

Again, if you happen to have a UID, let's say you need to look up the owner of a process, all you have is a UID. You can create a query on the POSIX identifiers. You can create a query for group members if you want to enumerate the group membership, and you can create a query for the current user to find out that user record.

There's two ways to execute queries. The simple way is synchronous query execution. And it's simple because it's very procedural. You create a query-- three function calls here-- creating a query. This one's looking for users in the local identity authority. So it's going to give me all local users. You execute it, csidentityquery execute.

When it's done, if it returns true, you say csidentityquery copy results. And you get back an array of all the identities. If the execution returns false, then you've got an error in the third parameter to the execute function. And for those of you who didn't hear about CFError, I hope it was covered in one of the Core Foundation sessions.

But there's a new error object called cferrorref. It's based on the NSError API. And it's a nice way to return errors because usually they have localized strings associated with them, as well as underlying error information. So if you get back an error as the return from a cferror-based function like this, then you have to make sure you release the error if the function returns false.

Now, the problem with synchronous queries is that they might take a long time. They might block. They will almost certainly be doing local I/O, but if you're running against the default identity authority and the system is bound to some directory server, then you're going to be hitting the network also. And so certainly if you're a single-threaded app and you're looking at queries on your main thread, you don't want to get the spinning pizza of death. So we recommend generally that you use asynchronous queries using a pretty standard callback model.

Another advantage of asynchronous queries is that we wanted to make it easy to get change notifications. It's not that unusual to be working with an access control list in one application and somebody switches over to account preferences and creates a new user or a new group. And it might be appropriate to have a system that's not always the same as the previous one. But it's not that unusual to be working with an access control list. So we wanted to make it easy for that new user to show up in the applications query that it happens to be looking at.

And so if you use asynchronous query execution, you get change notifications for free. The way that works is you create a callback function and events happen on the query. Mainly three kinds of events: added, changed, and removed. And you get passed an array of identities that are not the same as the previous ones. So you get a bunch of added events that come in in batches.

And the array indicates which identities are added. If you leave the query running because you haven't stopped it, then you'll get changed events or even removed events if either an identity is deleted or, let's say, you're doing a name-based query and the name of the identity gets changed. So if you leave the query running under query criteria, then you'll get a removed event for that identity. So removed doesn't necessarily mean it's been deleted.

To execute asynchronously, you just call CS Identity Query execute asynchronously. You pass in the query and some options, a client context structure, which includes your callback and a reference constant that you can control. And then you specify just a single run loop and run loop mode that you want to receive your callbacks on. And in many cases, you just specify the current run loop and the default run loop mode.

Now, whenever you start a query asynchronously, if you just release it, when you're done with it, you're not necessarily guaranteed that your callback won't be called anymore. So as with other asynchronous APIs on the system, you want to make sure you call CS Identity Query Stop. Because releasing doesn't necessarily mean that the object is going to be deleted right away. Because you don't know really what the ref count is for sure. If you say stop, then it clears out your callbacks. And that's the signal to us that we will not call your functions anymore.

Once you have an identity, say retrieved from a query, there's just simple getters for all of the attributes such as get the UUID returns a CFUUIDRef. You get CS Identity get full name. CS Identity get class I mentioned that returns an enum value. You can test, say, if it's a user, then you can call CS Identity get certificate and that returns the sex certificate ref.

These are all CF objects. However, because the functions are getters, it's very convenient. You don't have to release any of the values retrieved here. By the way, if you happen to call CS Identity Get Certificate on a group, it's not going to crash or anything. It's just going to return null.

Most applications aren't going to need to modify identities. Some applications might want to use a group as their access control model. If you have a service that runs as root or as a privileged user, you might want to create a group to represent your ACL. But most applications aren't going to need to actually be creating users.

However, the API supports it. If you're an admin user and you go through the Authorization Services authentication dialogue, then you can create users and groups, change attributes, and it uses a commit model. So you can call setters on an identity, and then you say, "Commit this," and it writes it back to the authority.

It can be committed either synchronously or asynchronously again. Simple example, set full name and then CS Identity commit. So that is a real quick overview of the API. And now I wanted to switch over to the laptop here and show you some sample code that's available on the session website.

It's called Identity Sample, and its purpose is just to exercise the API and serve as sample code for you guys. We have a sidebar on the left here which shows all of the local users, some of the people in my group. So it's doing initially a query for all the local users.

It can also do a partial name match query. So as I type, as soon as I pause typing, it starts a query for identities beginning with MAR, and it finds all the marks. By the time we ship Leopard, you'll be able to search by last name also automatically without doing a different query.

I can select an identity and it shows all of the detailed attribute values over on the right, including if there's an image, it shows it. I can click the plus button if I want to create a new one, new user. I'll go ahead and create Charles Darwin. And if I don't assign a password, there's actually no password.

And what I mean is they can't authenticate. It's not a zero-link password. It's like disabled user. But I'll go ahead and assign a password. And there's Charles Darwin. If I want to go and, say, add that nickname Chuck, I can do that. And maybe add an email address.

And when I'm done with the changes, I click the Apply button, and that calls CS Identity Commit to write the changes back to the store. So pretty simple application. And as I mentioned, it's available on the website for this session along with preliminary documentation for the API. Back to slides, please.

So, of course, end users have a need to do the same kinds of things that that application does. So what we've done, if you haven't seen it yet, on Leopard, you can look at the Accounts Preference pane and see that there's more stuff going on now. You can actually see the different kinds of users and groups over on the left. It has My Account still up at the top, and then there's a section for sharing accounts or sharing users, and a section for groups down at the bottom.

In this example, I clicked on the Core Services group, and it shows the membership over on the right side. It's pretty simple to add somebody just by checking the checkbox. So that's what Accounts Preferences looks like. It's sort of the central place on the system that we use to manage users and groups.

And now we can finally go back to picture sharing. We have enough infrastructure to be able to add access controls to the picture sharing application. So here's what it looks like currently. And we want to be able to set up an ACL. So we're ready to do step one. And to kind of show you what that looks like, I'd like to please welcome Alex Aybes up to give us a quick view of the new picture sharing server.

So like Chris mentioned, we want to be able to share photos with a restricted set of people, not allow access to everyone. So to do that, we have updated the Picture Sharing Sample Code, the Picture Sharing Application. And I'm going to show you what we've done to it right now. So here's the picture sharing application. You just saw the original one on the slide. So like you can see, we've updated the UI. We've added a couple of radio buttons, a list, and the plus and minus button. This is-- I'm going to show you how this works.

This is the UI we recommend you adopt in your applications when you want to do access control list management. This is what it should look like, and this is how it works. So the first button, Share with Everyone, maintains the current functionality. Anyone, everyone can access the photo.

The second button that I'm going to click right now, you see that it enables the list. We have now enabled authentication. Access is restricted. In the current state, no one can actually connect and see that photo. So now we've enabled authentication. We need to add people. How are we going to add people to this list? Well, for that purpose, we are providing, introducing in Leopard, a new standard panel that we call the Identity Picker. And this allows users to pick identities.

So let's say I want to share this photo, this beautiful ladybug, with my mom. She also happens to have an account in this computer. She can log into that machine. So I want to share this photo with her. What am I going to do?

And Chris is not on my Mac, and I've never shared with him, so he's not in the sharing users.

But I know I have him on Address Book, so all I have to do is select the Address Book icon and click on Chris and press Share. Since I've never shared with Chris, I need to set a password for him. So I'm going to set a password for Chris.

Don't repeat it. It's one, two, three, four, just for when you need to log in. And go share. And that's all I really need to do. Under the hood, we have just created an identity, just like we would have done the identity sample, but showed the minimal UI to the user. This is not to scare them too much.

The other thing I wanted to mention is that now that you've done this, all these identities are available throughout all the applications that use the Identity Picker. So you're going to be able to see the sharing users in any app that uses it, as well as in the system preferences, the accounts preferences, the identity sample, anywhere you go.

Like I mentioned, the API is extremely simple. There's just a couple calls. You can get a modal dialog, a sheet, whichever you want. And in those two cases that were fairly different as far as what we had to do-- one, we had to just pick an identity and return it, the other one, create it-- the API, you don't have to worry about any of that. You don't have to worry about creating it. All you do is call the method to bring up the dialog and then handle and process through the identities it returns. So that's it for the demo. Back to you, Chris. CHRIS BROADFOOT: Thank you.

So as Alex mentioned, sort of like a file open panel or the AB person picker, the address person picker, the Identity Picker insulates your app from not only the UI details of browsing, but even from the details of, say, being able to write from within the context of your application, promote Address Book entries to sharing users. So that they actually have a credential. So that little sheet that came down prompting for a password, that was not implemented by the app. That was still all part of the Identity Picker panel.

So that's pretty nice. It simplifies all of that for your app. It keeps people working right in your application to edit access control lists. However, I do need to mention that it's still a work in progress. I'm sure that the UI is going to go through some more change before Leopard ships. And that probably means the API is going to change somewhat also. But it's available in the seed if you want to play with it. It's part of the Address Book framework, abidentitypicker.h.

Alex also mentioned the API was pretty simple, and here it is. AB Identity Picker, alexinit, creates a picker instance. And then you call the method beginSheetModalForWindow, specifying the parent window, a delegate object, and the didEndSelector is the delegate method that gets called when the panel is complete. And at that point, it passes you an array of identities.

All right, finally, we're now to step two, persistence. We have an ACL in the application. We could enforce it while the application is running, but if we quit it and restart it, we want to keep that ACL associated with the shared resource. This is not terribly complicated, but you have to have a simple way to serialize or flatten your ACL into data.

Conceptually, an ACL is just an array of identities that might be just the identity, or it may-- each identity may have a read/write privilege, something like that associated with it. It's an application-specific thing. Every application has different needs. But the fundamental need is you need to be able to take an identity that's an entry in your ACL and turn it into some sort of data reference that you can use to restore the identity when your app launches again. One way to do that is with the UUID. I mentioned everything-- every identity gets a unique UUID. We've been doing that, actually, starting in Tiger.

But on Leopard, you can use the UUID. But we actually recommend something a little different, which is a feature of the API called Persistent Identity Reference. And it's just a data blob. You ask an identity for its data reference, and you get a data blob back. One of the things in there, of course, is the UUID, but it gives us the flexibility to put other things in the persistent reference that help us, A, find the identity faster when we need to look it up, and B, know if it's been moved to a different machine and do the right thing, just in case we want to know that this identity blob really isn't valid on this machine.

So how does that look? One call, CS Identity, create persistent reference. So that takes an identity, gives you back a data ref, which is your blob. You save that in your preferences file or whatever you're using as a data store for your shared resources. And the inverse operation then is to create a query based on the persistent reference.

So when you need to turn that back into the same identity object it was created from, you CS Identity query create for persistent reference and pass in the data, execute the query. And assuming the identity still exists, you get back-- the result is the identity that you want.

All right. Step three, authentication. Well, authentication is actually the hardest part. So I'm going to save that for last and go around to authorization. Authorization is still working with the ACL, so it fits in flow-wise a little bit better here. So authorization is when a connection comes in, you've gone through authentication, so you know who the connection is coming from.

Let's say then the result of the authentication step is an identity object, which represents the user making the connection. And you simply want to know, is this a user that actually has access, in this case, to the photo that we're sharing? And so basically you have to compare the entry or the identity against the entries in your ACL. And by the way, you might have groups that have been added to the ACL. We didn't show that, but you can add groups to an ACL.

So that means you need to write-- this is the simplest case, is what we do in picture sharing. If you have the ACL represented as an array of identities and you have an identity ref, which is the user that's connecting, you create a loop through every entry in your ACL.

And if the entry is a user, you use CFEqual to compare the entry to the connecting user. CFEqual is implemented in CS Identity such that if two different objects really represent the same person or identity, then CFEqual returns true. So you use CFEqual for user entries. If the ACL entry is a group, then you check group membership on it.

You say, is the connecting user a member of this group? And if so, if either of those ends up being true, then the user has authorization to access the resource. So that takes care of everything except authentication. Like I said, this is a little trickier. Everyone does authentication differently. There's a lot of different protocols.

One way to do it is simply implement your own. So let's say you want to prompt the user for a password on the client side of your application and send the password over to the server. And you can basically then look up the username, use the Identity Services API to say, is this the right password for this user? And you're done. You've got your authentication. But that's a lot of work for your application. You've got to do all of the UI. It means every application has a different user experience for doing authentication. You've got to worry about not passing the password over the wire in plain text.

And there are other issues like, well, then there's no way through your application anyway for the user to change their password, for example. So there is a better way, which is called a Network Authentication Service. It kind of abstracts the whole authentication process away from your application, insulating your app from the authentication process. And this has a lot of advantages. So for example, Kerberos is a network authentication protocol.

And it has a lot of advantages. Kerberos has been around for a long time now. And so it has very nice security features. For example, the password is actually never even sent over the wire. It uses this nice little exchange of encrypted messages to pass tickets, to grant tickets, which prove to an application that the connecting user is who they say they are.

It's an open source standard created at MIT about 20-some years ago. And it also has a single sign-on model. Once you get a ticket from Kerberos, it's usually good for several hours, which means that the application, other applications, can use that same credential pulled from the Kerberos credential cache. And the user doesn't have to go through an authentication step, again, to connect to the same machine or any machine that's part of the same Kerberos realm.

But there are some disadvantages, some downside to Kerberos. It typically requires a lot of maintenance and a lot of administration. It doesn't really account currently for ad hoc and mobile networks. And finally, the user usually has to know something. They definitely have to know they're using Kerberos and be a little educated about what Kerberos is and what it's doing.

So what we'd like to do in Leopard is build on what we've done with Mac OS X Server, which has been very successful. It makes setting up a Kerberos realm really easy. And maintaining the Kerberos user database in sync with the X Server user database is all tightly integrated. And so we want to build on that and build a Kerberos server into every Leopard client.

I'm glad you clapped. This is pretty cool, and it's a real challenge because essentially we're saying we want to take care of all of those disadvantages that I listed on the last slide. So the real goal is the user shouldn't need to know that they're actually using Kerberos. It means that all of the administration has to happen automatically. Every time you create an Identity Services user, they have to be set up as a local user in the Kerberos principal database.

It means we need to be able to integrate Kerberos with Bonjour Discovery so that we can find the KDC for a given application server. And we also want to make sure that, as I said, the user shouldn't really need to know that they're using something called Kerberos or what our realm is, but they should get all the advantages of using Kerberos. So we want to make a great user experience. And we've been talking to the Kerberos team at MIT about this for a while. And they're pretty into it too.

So there's still some problems to solve. It's not all there by any means in the leopard seed that you got at the conference, but We will be working out all the last issues before Leopard ships. And what that means is your application, when it's running on Leopard, can assume universal Kerberos availability when connecting to other Leopard systems. And this means if you have an application that wants to work in an ad hoc environment but also needs to work in a higher security, kind of a static, traditional Kerberos environment, you have a single authentication architecture that you can build into your application.

It does mean you need to adopt Kerberos authentication in your application. So what are the choices for doing that? Probably, if you're not familiar with Kerberos like I wasn't a couple years ago, it always sounded kind of scary, especially if you looked up the header files and took a look in there. Because one choice is you can write direct to the Kerberos API, which is a fairly complex thing and something you might want to do if you're already familiar with it or you've already adopted Kerberos.

But there is another way to go, which is a layer above that called the Generic Security Services or GSS API. It's sort of a high-level way to take a network connection and use it to fairly... Well, I'm not going to lie to you. Yeah, I am going to lie to you. It's really simple.

No, it is easier to adopt because it has a model that assumes you're making a network connection, and it's particularly easier if you have some good sample code to go from. And that's what we're trying to do with the picture sharing enhancements is produce a complete application that does access control, also does GSS authentication, because it's a fairly straightforward recipe once you have some code you can use.

And so GSS is our recommended way. If you want to fully adopt Identity Services and the preferred authentication model on Leopard, then this is the way to go. One of the other advantages of GSS is once you've gone through the authentication steps, it's really simple to basically create encryption and signing capabilities for anything going over the network.

And that's, again, exactly what we're doing in picture sharing is once you have an authenticated connection, we can GSS wrap the picture data and GSS unwrap it over on the client side so that it's all strongly encrypted on the network. So that kind of summarizes what we did to picture sharing. And Alex and I would like to show it to you now. If you remember, we need the laptop.

So Alex left the server running, showing the Ladybug picture. And I have access to the picture right now. So I'm going to go ahead and bring up Picture Sharing Browser. There it is. It's got the service list over on the left and a spot to show the picture on the right. And just to show kind of the machinery, this is just for credibility here, I'm going to launch the Kerberos app, which shows what Kerberos credentials are in the credential cache.

CHRISTIAN LANDRIFF: Which is nothing at the moment. And here goes nothing. I'm going to go ahead and click on Alex's service. And we actually are getting to a fairly normal looking logon dialog. It says, please type your account name and password for Alex's Mac. So it tells me I'm connecting to Alex's Mac. It's asking for my username and password. And it wants to know if I want to add that to the keychain. This is, in fact, a modified Kerberos authentication dialog. So when I go ahead and connect, I see the picture. And we get tickets in the ticket viewer.

So that worked. That was great. Very exciting. But what happens if I quit the app and I see that the ticket viewer or the Kerberos app still has my tickets there? So in theory, I can go back in to Picture Sharing Browser and click on Alex's service again. And single sign-on allows us to use the credentials in the private credential cache for the user. There's no authentication needed again.

Now, they're into it. Good. Yeah. Now, let's say I go home, and I come in the next day, and my tickets have all expired. So I destroy my tickets. There's no more credentials in the cache. I can go in, launch Picture Sharing Browser, Click on Alex's service. I do have to authenticate again, but because of keychain integration, the password has been pulled out of my keychain for Alex's Mac. And I just click OK, and I'm in.

So now, if I don't want to share this photo with you anymore. ALEX KOMOROSKE: What? No. Yeah, no. Don't ask me why. I just don't want to. ALEX KOMOROSKE: Alex is removing me from the ACL. And there, you're gone. ALEX KOMOROSKE: And the way we wrote this application-- well, the way our colleague wrote this application-- thank you, Mark Krakmal-- it's always waiting for more data from the server.

And so as soon as he revoked access to me, we just sent an error over the network. And immediately, I was denied access. And now Alex is going to go ahead and add me back in. We're friends again. We're friends again. You may view my ladybug again. ALEX KOMOROSKE: And boom. We get access again. So we've done the authentication and we have live authorization. Not all apps need to do instantaneous access controls like that, but it helps illustrate what's going on with our application. All right, thanks, Alex.

So just to recap, the four things we went through, we added ACL editing to the server picture sharing app. We save that ACL. We didn't actually show that, but you can quit the server and restart it, and it loads up the ACL again. We added GSS-based authentication to picture sharing.

And last step, we enforce the ACL by looking at every entry and comparing it to the authenticated identity coming in. So that is most of what I wanted to talk about. We've got a few minutes left. And I wanted to say a little bit more about Kerberos, because it does get a little bit better from here.

Kerberos is-- because it is open source and it's been around a long time and has a lot of people working on it, industry standard and all that, If your app adopts it, you get all of the future enhancements to Kerberos moving forward. And because you have adopted an abstraction of the whole authentication process, then it means Apple and Kerberos can control the user experience, the kinds of credentials that the authentication process uses.

And I want to talk a little bit about Kerberos PK-ANIT, which is an extension to Kerberos. It's, I guess, a variation on K-ANIT, which is the Kerberos log command line tool. PK-ANIT is a public-key infrastructure-based authentication scheme. So if you have X.509 certs associated with your users, you can use cert-based authentication through Kerberos. and essentially have no password authentication for users.

So .Mac is, the .Mac team's pretty into that, and they're interested and currently pursuing issuing essentially Identity Certificates through .Mac in the same way. And this is planned to be a free service. You don't have to be a .Mac member to be able to use it.

Anyone can get a handle through .Mac. And our plan is to tightly integrate this with Identity Services and pretty much attempt to replicate the kind of transparent experience you have working with iChat encryption. So again, this isn't, of course, available in the WWDC seed release, but we're working hard on it.

So now I really am done. In summary-- We talked a lot about Identity Services as the foundation for working with Identities on the Mac. In that architectural diagram down at the bottom, I had Darwin. And in the Darwin box, I just had Open Directory. But I wanted to point out that, in fact, if you adopt Identity Services, it really abstracts you from other things too.

So for instance, I could go back to the diagram and add Kerberos into the Darwin box. If you work with Identity Services, it means you're abstracted from whatever we do under the API to make the whole user experience of authentication and working with access control lists that much better.

Start investigating. If you're not familiar with Kerberos, sounds like some of you are because we got some applause. That was cool. But this is something you're going to be able to count on being available on all Leopard machines. And we hope to have more to say about .Mac Identity Certificates in the not too distant future here.

So we don't-- they compressed the schedule on Friday here because, well, I guess we have to be out of here by noon or something. And so we don't have time for questions. The next session actually starts in 15 minutes. But for some reason, they called our lab the Identity Picker Lab, but it's really the Identity Services Lab. And it starts at 11 o'clock, which means we're all late already. We're just going to be walking down to the Mac OS X lab, and we'll be happy to take your questions as we do that. So thanks very much.