Oren Sreebny's Weblog

« [Windows Live @ edu] Intro | Main

June 22, 2006

[Windows Live @ edu] Identity Management

Cobranding coming later this month.

Matt Sullivan, Program Manager - Windows Live ID Managed vs. Federated Namespaces...

Definitions:

Service Provider - app that needs authentication
Identity Provider - service where authentication can be established.
Single Sign On - a user experience, not a technology.
One Way SSO vs Two Way SSO -
Federation - authentication distributed among multiple, trusted ID providers
SAML
Shibbloeth
WS-* - Web Services standards based on SOAP/XML. specifically WS-Federation: Passive Requestor Profile - a messaging protocol that can use SAML among othe rstandards, such as Kerberos, for the identity claims.
Infocard - a new approach to authn where the user is the ID Provider. Live ID supports this.

Today's Architecture

- Windows Live ID is the sole ID provider ofr Windows Live Service Providers
- School manages namespace in Windows Live ID service - eg they "reserve" the namespace and then administer the accounts using MIIS.
- Client cert in Windows Live ID associated with the administrator role for a namespace. Cert will have to be from a recognized provider, but there's some discussion about this - maybe they'll just trust uploaded public keys.
- student receives from school an email address plus temp password. student gets asked to input alternate email, secret question, etc.
- most schools act as separate IDP
- students have separate passwords for their IDP from Windows Live unless they sync manually.
- Credential names are not necessarily synched, but often are.

The "Portal SSO" Ask

- Many schools ask for One Way SSO, a link on the portal so a student can get to his/her Live Mail inbox without re-authenticating

- a solution is available today...
- Live ID (login.live.com) can issue tokens to RPS on win32/64 or to other platforms via SAML
- School installs RPS or consumes SAML from Live ID instead of, or in addition to, hosting their own auth system.

Many schools have reservations -
- dependency on external authn service for internal apps
- trust.

Approach 1 - Managed Namespaces

- Architecture remains identitical to today - accounts are pushed to Windows Live ID so 2 IDPs
- New API is provided so school can obtain Live ID auth tokens for Students
- API is called only after internal auth is established on the portal, with the corresponding sschool ID
- School may or may not opt to sync passwords
- School may wish for synced logout state

- student authenticates on portal - portal passes back a link to mail, student clicks link, portal sends a request to Windows Live via SOAP/SSL (request includes timestamp of last password authn), portal gets back a short-lived-token, passes that back to student in a 302 http message, which redirects to Windows Live ID Login Service, then they pass back a ticket for the service provider, and then you get a 302 redirect to the inbox.

Password Synchronization -

- Not required for API usage but usability may suffer
- Scenarios
-- Inbox is reached via school portal, time passes, re-auth is required, UI is then serviced by login.live.com, not the portal - what does the student type for password?
-- student might reset password on portal - do they realize they have two accounts with different passwords?
-- what about people who go direct to Windows Live Mail?
-- what about desktop clients like Messenger that go right to Windows Live ID?

Federation
- school is known to windows live as the sole IDP for the namespace
- school produces wws-* containing saml claims which windoes live ID turns into tickets for Windows Live Service Providers
- out of box support for ADFS
- windows live ID service stores only the credential name not the password
- windows live ID redirects all login request sfor users in that namespace to the school.

Walt will set up a separate call or meeting on identity management.

Technorati Tags: microsoft, WindowsLive@edu

Posted by oren at June 22, 2006 10:39 AM

Comments

Post a comment