keystone-hackathon.md

OpenStack Keystone Hackathon

Don't hesitate to get in touch if you need anything: @dolphm

Date

End of Icehouse milestone-2 development:

• January 15-17th, 2014 (Wednesday, Thursday, Friday), 9:00am to 5:00pm

Location

Customer Experience Center, immediately inside main entrance of Rackspace Headquarters:

• 5000 Walzem Rd, San Antonio, TX 78218

Which is the exact same location as our new street address:

• 1 Fanatical Pl, Windcrest, TX 78218

Lodging

• Marriott Courtyard (preferred by most attendees)
  • $99/night if you mention you're with Rackspace (contact me if you need help here)
  • Free shuttle service to Rackspace @ 7:15am, 8:15am, 9:15am
  • Free shuttle service from Rackspace @ 3:15pm, 4:15pm, 5:15pm
• Hotel Valencia
  • $114/night if you mention you're with Rackspace (contact me if you need help here)
  • Valet parking only (garages nearby); valet fee possibly waived if you claim to be with Rackspace

Attendees

Contact me to be added to this list!

1. Adam Young (ayoung) (Red Hat)
2. Ade Lee (alee) (Red Hat)
3. Bo Tang (UTSA)
4. Brad Topol (btopol) (IBM)
5. David Stanek (dstanek) (Rackspace)
6. Dolph Mathews (dolphm) (Rackspace)
7. Endi Dewata (edewata) (Red Hat)
8. Farhan Patwa (UTSA)
9. Henry Nash (henrynash) (IBM)
10. Khalid Zaman (UTSA)
11. Morgan Fainberg (morganfainberg) (metacloud)
12. Prosunjit Biswas (UTSA)
13. Steve Martinelli (stevemar) (IBM)
14. Xin Jin (UTSA)

notes.md

Token as a result of federation

This is now outdated! Continued in code review.

• Identity providers assign user names, which don't have to be globally unique.
• Keystone assigns user IDs, which are globally unique.

User IDs are expected to be URL safe, and are therefore URL-encoded (in this example, the user name "username@example.com", becomes the globally unique identifier by the identity provider, is URL-encoded using urllib.quote().

{
    "token": {
        "user": {
            "id": "username%40example.com",
            "name": "username@example.com",
            "OS-FEDERATION:protocol": {
                # "id": "saml2",
                "links": {
                    "self": "http://localhost:35357/v3/OS-FEDERATION/identity_providers/CERN/protocols/saml2"
                }
            },
            "OS-FEDERATION:groups": [
                {"id": "abc123"},
                {"id": "def456"}
            ]
        },
        [...]
    }
}

Mapping has two goals:

• Identity: Map a federated attribute to represent the user's identity within OpenStack (dynamically assigning a user name).

• Authorization: Map all other federated assertions into OpenStack-managed groups. (Groups have role assignments, and therefore convey authorization to federated identities)

The output of mapping is a dict which is a subset of the above user object:

{
    "name": "username@example.com",
    "groups": [
        {"id": "abc123"},
        {"id": "def456"}
    ]
}

Use cases for having users "in" domains:

• Namespacing user names to allow "duplicate" names.
• Delegated management of user collections when keystone is the IdP.

Identity providers are the source of users. Domains are the logical grouping of users.