Overview

People Picker is a federated white pages that is implemented as a web-service.

A federated white pages gives you the ability to search for individuals anywhere in your federation from the one place. You only need to log in once and you can search all the institutions for the person you are looking for.

For example, imagine I was in a federation of universities that had 12 institutions within it and I was looking for a physicist who could give me a quote about the federal governments new "quantum particles tax". I could go to the federated white pages, search for "physics quantum" and I would get a list of all people that fit that description. Much easier than searching institution by institution!

By implementing it as a web service, you can access the white pages from anywhere. Plus, federations can create custom interfaces to the functionality.

Features

• You can search for a user across a whole federation in one go.
• Secure - all data is encrypted.
• Secure - shibboleth release policies are enforced.
• Secure - all searches are shibbolized.
• Search results are incrementally returned.
• Search progress is indicated as search proceeds.
• Searches are fast (only seconds to access a whole federation).
• You can search for approximate or exact matches.
• Custom clients are easy to create.

Architecture

People Picker is implemented in 3 parts

• idp-pp: an idp component that exposes user search as a web-service
• fed-pp: a federated white pages component that takes a single search and does the hard work of performing that search on all idp-pps. It will then return the list of results. All input and output to fed-pp is done via web-services
• clients: the programs (either web sites or applications) that users of the search functionality actually use. These pass the requests on to fed-pp to do all the hard work. You can think of them as interfaces for the people picker where fed-pp is the logic of people picker.

When we talk about people picker, we are talking about all of this as a whole. If we want to talk about individual parts, we will use the names fed-pp, idp-pp or clients. The following diagram show this architecture. Note that while there can be many clients in any one federation, there will most likely only be one. Note also that all internet traffic is encrypted.

Information Flow

It is useful to see how information flows within people picker

1. the user types a query into a pp client
2. The client sends the query to fed-pp
3. fed-pp sends the query to each idp-pp
4. each idp-pp responds with results
5. when all results are back fed-pp responds to pp client (actually, people picker allows intermediate results and progress to be displayed as well).
6. pp client then displays results for the user

How do clients know what information will be passed to them?

Every federation needs to agree on a schema (for example the eduPerson schema). When you deploy people picker on your federation, you will need to also agree on a "search schema", which is a subset of the attributes in the federation's schema that idps agree to make available when they are searched. For more information, read the getting clients and idps to talk the same language page.