Live Identity services means different things to different peopleFor web developers building consumer web scenarios for customers it means you can tap into approx 500M identities of consumers and provide single sign on for those consumers in your application, provide access to Live Services in your application.ISVs who build solutions and sell them may think of Live Services as a way for people who use their application to be identified via the federation infrastructure. Imagine being able to on-board a new customer just by getting them to federate with the Microsoft cloud and instantly they can authenticate into your application.And for organizations, with cloud based services becoming popular we need to make sure the same concepts which exist around identity management in an on premises world carry over to the cloud. By providing a simple way for organizations to connect their identity system to the cloud it makes it super easy for them to adopt online services from both Microsoft and third parties.Today we will be focusing on the web developer scenarios and what you can do as an ISV to provide solutions to consumers and organizations.a
There are really 3 key areas of how we think about Live ID:General baseline functionalityIntegration points for partners and third-partiesFederation with third-party organizations where they are the identity provider
Support all services at MicrosoftConsumer (Live) + Enterprise (Online)Enable third-party integration tooFederation friendly and readyOpenness + Standards-basedRich functionalityEase of useFor both Developers and UsersAbove all – SECURE!
WebAuth SDK contains open source samples in 7 languages – C#, VB, Java, Perl, PHP, Ruby, PythonImportant: If the page addressed by your return URL or other pages on your site use Secure Sockets Layer (SSL), use \"https\" in the src attribute for the Sign in link. Customizing the Link When you insert the preceding code in your Web site, you must customize it a little for your application. Specifically, you must replace the values for the appid, context and style parameters (shown in bold in the example) with the proper values for your implementation. Parameter DetailsappidThe application ID that you obtained when you first registered your site. This query-string parameter is required. It tells the Windows Live ID authentication server where to sign in the user. contextThe parameter that holds user state for your application.For example, if the user is on your page www.example.com/xyz.htm, you can pass \"xyz.htm\" to the Windows Live ID service as context. When the user is redirected back to your site, you can send him or her back to xyz.htm to continue what they were doing before signing in. Note: To help protect against script-injection attacks, there are limitations on the strings that may be specified for the context parameter. Script of any kind is strictly forbidden. The Windows Live ID service will convert unsafe characters to safe characters or may discard the value that you provide altogether. We recommend that you handle state in your application by using your own proprietary cookies. styleThe set of attributes that help to make the sign-in IFRAME element fit your site visually. These attributes are defined according to Cascading Style Sheet (CSS) specifications. The following attributes are currently supported:font-familyfont-weightfont-stylefont-sizecolorbackgroundWhen you specify a value for the style parameter, you must supply these attributes in a semicolon-delimited, URL-encoded form. For example, the following is an example of an unencoded style string.font-size: 10pt; font-family: verdana; background: white;In contrast, the following example shows the same string after URL encoding:font-size%3A+10pt%3B+font-family%3A+verdana%3B+background%3A+white%3B
WebAuth demo – WebAuth SDK sample - http://localhost/webauth/sample/default.aspxDelAuth demo – DelAuth SDL sample 2 – http://localhost/delauth/sample2/default.aspxWindows Live Data Interactive SDK - http://dev.live.com/livedata/sdk/The stages of the web authentication flow are:User requests a Web page. The user, using a Web browser, visits your Web site for the first time and has not yet signed in by using Windows Live ID.Your site returns a sign-in link. Your site returns a page that displays a special sign-in link in an IFRAME element. User clicks the sign-in link.Windows Live ID returns the sign-in page. The Windows Live ID authentication service directs the user to its sign-in page.User supplies credentials. On the Windows Live ID sign-in page, the user types his or her Windows Live ID credentials (e-mail name and password) and submits the form.Windows Live ID authenticates the user. The Windows Live ID authentication server receives the sign-in request and validates the user’s credentials.Windows Live ID redirects the user to your site. If the credentials are valid, the authentication server responds by redirecting the user to your Web site along with a token as a FORM POST parameter. This token is proof that Windows Live ID has verified the user’s identity. Your site can decrypt this token to obtain the user's unique identifier. Your site displays protected or personalized content. After you have obtained the user's unique identifier, you can use it to store or display protected or personalized content. You can also choose to incorporate Windows Live Controls into your site.
UX customization is the top request from partners and the field – now delivered!
Remove
Pop out the differences
CTP release announced at PDC-2008 for testingFound and fixed some glitches in our implementation of the OpenID protocolLots of great UX feedback received so farCTP required creation of an OpenID alias. Production release will not require thisProduction release will allow use of normal Live ID accounts for sign-in
DelAuth demo – Import live contacts to Bebo – http://bebo.com/DelAuth demo – DelAuth SDL sample 2 – http://localhost/delauth/sample2/default.aspx
Identity Strategy Talking PointsOne identity model that puts users in control of their identities:Flexibility via ChoiceEnhances Developer ProductivityStandards BasedSlide NotesLive ID is an vIdentity Provider (IdP) with over 500 million active usersLive ID IdP is hooked in to the Microsoft Federation Gateway (MFG) Various ways to enable organizations to hook their AD users into the federation ecosystemMicrosoft Services Connector supports a simple, dedicated hookup to MFG onlyGeneva Server supports more complex federation requirements – Example: hookup to MFG as well as other federation connectionsMicrosoft provides a choice of frameworks and SDKs for both client and server integrationThird parties IdPs and RPs can also integrate with MFG through standard protocols such as WS-Federation or (future) SAML 2.0
Session: MIX09-T27F
Live Identity Services Overview
Web ISVs Organizations
Developers • Federation for • Turnkey
• Customizable selling their federation for
identity UX applications to adopting
• Single Sign On organizations services
• Access to user • Easy on- (Online, Live, IS
data boarding of new Vs)
customers • Works with
existing identity
infrastructure
Baseline understanding of Live ID
Web Developers
• Consuming Windows Live IDs on your site
• Accessing user data on your site
ISVs
• Consuming federated identities
• Rapid on-boarding for organizations
Identities • Authentication: users, applications, devices
Strong • Investing in 2FA such as Smartcard, StartKey
Authentication
Attacker Resistant • User / IP reputation, Account abuse prevention
UI Customization • Live ID is fully customizable
Data Portability • Delegated auth: user permission to access data
OpenID • Embracing Open Standards
Federated • Compatible with Microsoft Federation Gateway
Authentication
Type of identity
Principal Types Credential Types
Principal Acting for Self Acting for User • [Strong]
User User auth Password, Pin
(Client or Web) • eID / Smart card
Application App auth (AppID) Delegation (Good)
Impersonation
• CardSpace
(BAD!) • Policy-driven control
Device DeviceID Linked DeviceID
The Password
Types of Live ID Users Anti-Pattern!
• Live Mail / Hotmail accounts
• EASI (“E-mail As Sign-In”)
• Managed domains
• Federated domains
Consume Accessing user
identities & data
SSO • Delegated Auth
• Web Authentication SDK
• Client SDK
• Preview: Open ID
Live ID Web Authentication SDK Docs http://go.microsoft.com/fwlink/?LinkID=91762
Relying Party Web Site
1 e.g., Contoso.com
End User
w/ web 5
browser
4 2
3
Live ID WebAuth service
Recognizable & not jarring
Sign-in Sign-up Consent
Customizable Contents
Elements that can be
customized.
Partner Logo
Task statement
Product description
Task integration statement
Sign up section
Header background
Customizable Theme
Sign-up section
Elements cannot change.
Customize look & feel.
Font color
Background color
Button color
User tile color
Live ID description color
Microsoft is becoming an
OpenID Provider (OP)
Try the Live ID – OpenID Provider CTP Now
1. Set up a Live ID INT account: https://login.Live-INT.com/
2. Set up OpenID alias:
https://OpenID.Live-INT.com /beta/ManageOpenID.srf
3. Use OpenID 2.0 login URI: OpenID.Live-INT.com
4. Send feedback: openidfb@microsoft.com
>> Production release of Live ID – OpenID Provider
later this year
Consume Accessing user
identities & data
SSO • Delegated Auth
• Web Authentication SDK
• Client SDK
• Preview: Open ID
End User “Granting Consent” phase
with
browser
Consent UI
consent.live.com
Application
Provider “Using Consent” Phase (user can be offline)
(web site)
Resource
Provider (e.g.,
Windows
Live Contacts)
Live ID
Delegation
Service
Don’t panic! The SDK libraries handle all this for you!
ru=
ps=Contacts.View,Contacts.Update
pl=
ttype= 1: Compact token, 2: SAML token
mkt=
app=appid
Application Verifier token:
ts ip
sig
AppID, Timestamp, Client IP, SHA256 signature
appctx=welcomepage
Federation Rapid on-
Infrastructure boarding / tools
• Standards based • Microsoft Services
• WS-Trust/WS-Fed Connector
• Microsoft
Federation
Gateway
Benefits of federated identity
more services and applications
more customers
greatly simplify
User Applications Relying Party (RP) Identity Providers (IdP)
Client SDK
Live ID
Windows
App Microsoft
Web Site / Federation
Online App Gateway
Browser (MFG)
Live ID Other federated
Identity Identity
Provider Providers
Microsoft Federation Gateway Microsoft Services Connector
Hub and spoke Connects
auto-provisioning
Production customizable
2006
self-service Free
federation provisioning
Objective: Connect to cloud services without changing
existing identity infrastructure
Federation Rapid on-
Infrastructure boarding / tools
• Standards based • Microsoft Services
• WS-Trust/WS-Fed Connector
• Microsoft
Federation
Gateway
Using Federation Gateway & MSC
1. User clicks link -- 3. Services Connector issues login
token and redirects to Federation
Gateway
2.
4. Federation Gateway validates token
and transforms claims
5. Federation Gateway issues service
Browser token and redirects to service
Office 6. User accesses service
Desktop Apps
Microsoft Microsoft Cloud
Enterprise Services Federation
Applications
Connector Gateway
Developer
Active
Services
Directory
Web ISVs Organizations
developers • Federation for • Turnkey
• Customizable selling their federation for
identity UX applications to adopting
• Single Sign On organizations services
• Access to user • Easy on- (Online, Live, IS
data boarding of new Vs)
customers • Works with
existing identity
infrastructure
Live Identity Services presentation at Microsoft's more
Live Identity Services presentation at Microsoft's MIX09 Conference.
Learn how Microsoft provides a range of identity solutions for helping developers more easily build seamless user experiences that include Federation, Authentication, UX Customization, Open Standards, Open ID and more. less
0 comments
Post a comment