Contents tagged with LiveID
Here is the third part of my Visual guide to Windows Live ID authentication in SharePoint 2010. This part takes off just where we ended the last part. If you haven't read part 1 and part 2 then make sure to read them through before continuing.
Submitting site for compliance
In order to get your INT site into the PROD/production environment you need to make sure that your site follows the compliance rules. If you do not follow the rules then you will not be able to run your site using the "normal" Live ID accounts. The compliance criteria and verification cases can be found at the MSM site as Word or PDF format. Note that this document is dated way back in 2006 so some things are quite outdated. Here is a short but not complete summary of the compliance criteria:
- Must work with Internet Explorer 6.0 or later (don't think this one is valid though, since I got my SharePoint 2010 site approved - aim for IE7+ support)
- A link to your Privacy statement must exist on the first page and this privacy statement must include a link to the Windows Live ID privacy statement
- All first-level pages must have a valid and functional Sign In text or valid Live ID Sign In button
- There must be a Sign Out link (or image) when logged in
- Windows Live ID must be correctly spelled and have the trademark symbol at first mention
If you are going to use images for the Sign In and Sign Out links - you must use the official ones. And you must have them point to the original location.
Once you believe that you meet the criteria's it is time to submit it for approval. In the MSM site go to your site and select Submit for compliance.
This link takes you to a wizard where you have a link to the compliance criteria and verification cases documents. The wizard has two pages. On the first page choose Yes in the drop down (if you meet the compliance requirements). Then click Next
The second requires you to enter information about your site, test environment and anticipated launch date. You also have to option to write some notes to the tester. Once you have entered the information click Submit.
When you're done you should see a message that the site is successfully submitted.
Now all you have to do is wait for a response from the tester. This can take anything between two days to two weeks. While you are waiting you can see the current status of your site in the MSM site. The image below shows that; (1) your site is pending, (2) you cannot longer submit it for compliance and (3) it is not yet submitted to production (this is the next step).
You will receive answer after some time and it can either be negative or positive. I've actually had some problems at first - the tester did not see the standard (OOTB) Sign In link in SharePoint 2010 (probably due to the 115% zoom bug in SP2010). But once it was approved I received an email like this:
Submitting for production
When you are approved but before you can use the site in the PROD environment you need to go back to the MSM site and submit the site into production. This is done on the manage site page. The Site Details will look like this before submitting to production.
To submit the site to the PROD environment choose the Submit Site Properties to Production link in the Tasks below the Site Details:
Once you have clicked that link you will be asked to specify the production environment details. The most important thing is to change the DNS Name. As said in part 1 you must use a URN instead of a URL. If you have a URN like this
urn:wictorslivesite:intthen create a URN looking like this for production:
When you are done click Submit and on the next page verify that all your properties are valid. Once you are ready click the Yes button to finalize the submission to the PROD environment.
The Site Details should look like this when everything is set and done.
Configuring the PROD site
Enough of fiddling in the MSM site - let's take on SharePoint 2010 instead. These steps are pretty much the same as for when configuring the INT site - with the difference that we use another certificate, the new DNS Name, a new login URL and new accounts.
First you need to get the PROD certificate. Go to https://nexus.passport.com/federationmetadata2/2007-06/federationmetadata.xml and extract the signing certificate. Copy the inner text of the X509Certificate element into an empty Notepad document and save it as LiveID.cer.
Start a new MMC session and add the Certificates snap in. Import this certificate into the same three locations as you did with the INT certificate; Trusted Root Certificates, Trusted People and SharePoint. Make sure to do this on ALL WFE and application servers in your SharePoint farm.
Note that you do not need to remove the INT certificate if you are using the same farm/servers for PROD and INT.
Next is to fire up PowerShell and do basically the same procedure as for the INT site. The difference is highlighted in red below:
1: asnp microsoft.sharepoint.powershell 2: $realm = "urn:wictorslivesite:prod" 3: $certfile = "C:\Temp\LiveID.cer" 4: $rootcert = Get-PfxCertificate $certfile 5: New-SPTrustedRootAuthority "Live ID Root Authority" -Certificate $rootcert 6: $emailclaim = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "http://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming 7: $upnclaim = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" 8: $authp = New-SPTrustedIdentityTokenIssuer -Name "LiveID" -Description "LiveID" -Realm $realm -ImportTrustCertificate $certfile -ClaimsMappings $emailclaim,$upnclaim -SignInUrl "https://login.live.com/login.srf" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
On line 2 you must use the PROD DNS Name/URN. On line 3 you need to use the newly created Live ID certificate On line 5 use a different name of the trusted root authority, compared to the INT site On line 8 when creating the trusted identity provider specify a different name (than the INT provider) and use the PROD Sign In Url.
Then go to Central Administration on your site and select the Web Application that will use the Live ID. Configure the authentication providers to use the new trusted identity provider. If it is the same web application uncheck the INT provider before checking the PROD provider and save your edits.
Only one thing more to do. The INT and PROD environments uses different Unique User Identifiers for the logins. If Live ID is your only authentication provider you need to configure a new site collection administrator for your site collections. You can find the Unique ID on the Live ID Account Overview page.
Use that ID and append @live.com and use that when configuring your site collection admins:
That's it - you are now running your SharePoint 2010 site using Windows Live ID login! Use the same procedure as in part 2 to assign permissions to all users out there...
This also sums up this series on configuring SharePoint 2010 for usage with Windows Live ID. I hope that you enjoyed it and avoids falling into some of the traps that I did along the road. Possibly (but not guaranteed) I will have some follow-ups on this series with some more troubleshooting and interesting tidbits found on my journey!
Keep on SharePointing!
Oh, and if your in Singapore next week for the Southeast Asia SharePoint Conference just come by and say hello and I'll give you some great discount on my SharePoint book - SharePoint 2010 Web Parts in Action.
UPDATE 2012-02-01: A new and better approach to this is detailed in a new Visual Guide - Visual guide to Azure Access Control Services authentication with SharePoint 2010.
I'm back with the second part of the Visual guide to Windows Live ID authentication with SharePoint 2010 series. Part 1 was a huge success and has received a lot of feedback and hits - I hope many of you out there successfully configured your web sites and extranets. I'm currently working on getting the new Swedish SharePoint User Group website up using Live ID...
This second part will continue where we left it last time, and this time also using a lot of images. Jeremy Thake (MVP), who currently working on a secret SharePoint project, blogged about some of the things I will detail in this post, so for some of you there are stuff repeated in this post.
Give access to users
One of the first things you need to do is to give all Windows Live ID users the possibility to log in to your application. It's not mandatory but it is really hard asking for the PUID of all users and manually adding them to your site(s). The PUID will be seen by the user by accessing the Live ID account services at https://accountservices.passport-int.net/ or by signing in so they see the access denied page.
Instead of manually adding users you should add all authenticated Live ID users to a Visitors group for instance and have some kind of application form with a workflow or similar which they must fill-in to become "real members" (sounds like an InfoPath and SharePoint Designer task...). To add all authenticated Windows Live ID users to the Visitors group; log in to your site and select Site Actions > Site Permissions. Then select the Visitors group or any other group of your choice. Clicking New > Add Users will open up the Grant Permissions dialog. If you write anything in the Users/Groups field and click Check Names you will see that you can actually type anything and it will be valid.
The Live ID authentication provider accepts any string and it does not perform a lookup with Windows Live ID, so essentially you can use any string . But users will only be sent from Live ID to your site with a PUID (firstname.lastname@example.org), so you can't give access to a user without the PUID. If you write All users instead this will perfectly resolve to two interesting groups; The All Users (windows) and All Users (LiveID INT) - all depending on what authentication providers you have, in this case the standard Windows login and Live ID (INT) is enabled for the web application. If you select the All Users (LiveID INT) and add it to the group, all authenticated Live ID users will be a member of it.
You can also click the Browse icon and bring up the People Picker dialog, which has a new look when claims is enabled for the web application. To select the All Users group for Live ID select the All Users node in the tree on the left hand side and then select the All Users (LiveID INT).
Worth noticing here is you cannot "search" for a Live ID user - not by name, e-mail or anything. You always need the exact PUID or username when claims mode is enabled.
So, now you have allowed all Live ID users to log in to your site. Enabling anonymous access to users is no different than before. First you have to change the Authentication Provider of the Web Application (Central Administration > Manage Web Applications > Select Web Applications > Click Authentication Providers in the Ribbon > Select Authentication Provider). Just check the Enable anonymous access for the authentication provider and then click OK.
Next you have to enable anonymous access per Site Collection. Once again go to Site Actions > Site Permissions and click on the Anonymous Access button in the Ribbon menu.
Then select what the anonymous users can access; Entire Site, Lists or Nothing.
Once you have done this new users will not be required to log in to your site immediately. Instead they will see the "Sign In" link in the upper right corner.
The display name of the user
Once the user logs in to the site the user name still looks pretty ugly - it's just the PUID that is given to SharePoint from the Windows Live ID login service. Unfortunately Windows Live ID only returns one single claim and that is the UPN, which is in the form of a e-mail address. That e-mail address is not even a valid address. You can not expect to get the full name or e-mail of the user from Live ID - you have to implement something of your own OR use the built-in amazing stuff in SharePoint.
What amazing things do we have in SharePoint then? First of all - if you are on SharePoint Foundation, it's not that amazing at all. You have to live with the PUID or build something of your own and keep all your Site Collections in sync.
But if you are lucky to set up a SharePoint Server then you can take advantage of the User Profile Service Application. Configure the UPA according to all best practices - but do not configure the User Profile Synchronization (UPS), we do not need it and it does not synchronize with Windows Live ID anyways. Only configure the UPS if you are using both internal Active Directory users in combination with Live ID.
Once you have configure the User Profile Service Application go to Central Administration > Manage Service Applications and select the User Profile Service Application. Then click on Manage User Properties. We will do that to configure what properties the users are allowed to change.
You can change a whole lot of User Properties here, but the most important ones are Name and E-mail. We need to make sure that the user can edit those. Browse down to the Name property and select to Edit it.
To make the Name editable and usable there are a couple of things that we need to take care of:
- Make sure that the property can be edited
- Make sure that it is visible on the Edit Details page
- Choose if the property is publically visible on the profile page
- Choose if updates to the property should be visible in the newsfeed
- Make sure that the property will be replicated from the profile into the userinfo list in all Site Collections
Once you have configured the Name and Email property (at least) you are ready for a test drive. Log in to your site and choose My Profile from the login (upper right) menu and click on Edit My Profile. As you can see you are now able to edit the name, by default it is the PUID. Update the settings and click Save and Close and go back to the your main site.
Once you get back to the site you will probably see that the PUID is still there, hold on and don't start crying yet. It takes some time to synchronize between the user profiles and userinfo lists. You can speed up the process by running the "User Profile to SharePoint Full Synchronization" job - normally run once an hour.
After a successful sync you should see that the upper right menu shows the Name that you specified in the user profile.
HTTPS and HTTP
There is one final thing that you should do before continuing with your site and submit it for the PROD environment and that is to allow users to browse your site without HTTPS. The login procedure must use and will still be using HTTPS. Fire up the IIS manager and select the web site that you have been using and select to edit its Bindings.
Add a new Host Header binding or other binding of your choice using the HTTP protocol and then click Close.
Then open Central Administration and select Application Management, under Web Applications choose to Configure alternate access mappings (AAM). Choose to Edit Public URLs and then select your web application. In the Internet Zone add the URL of HTTP address, using the HTTP protocol and then click Save.
Once this is done you should be able to browse to your site using the HTTP protocol, and then if you click the Sign In link you will be taken to Windows Live ID and be authenticated. When you are successfully authenticated Windows Live ID will redirect you back to the HTTPS address (remember that you specified the Return URL in the MSM using the HTTPS protocol, in part 1). From now on you can move seamless between the HTTP and HTTPS zones.
There are other options here as well, such as extending the web apps, but that is for someone else to write about...
That's it, you should now have a fully functional Windows Live ID enabled site. You can even edit the site using SharePoint Designer using the Live ID account. Next part will give you the details on how to move this site from the INT environment to production (PROD),
Until next time...
UPDATE 2012-02-01: A new and better approach to this is detailed in a new Visual Guide - Visual guide to Azure Access Control Services authentication with SharePoint 2010.
Using Windows Live ID as login provider for SharePoint is a really huge thing. It makes the scenario for public facing web sites, extranets etc. much more easier, for instance there is no need to maintain passwords and users in the same degree. For SharePoint 2007 there is no native support for this, so I built a custom Live ID login provider (available at http://spwla.codeplex.com), but SharePoint 2010 has native support for claims based access. And that is what's on the menu for tonight...
This post, and the subsequent ones, will show you how to enable Windows Live ID on a SharePoint 2010 farm (SPF or SPS). I will do a visual approach using a lot of screenshots. It has not been an easy path since there are no official guidance on this subject (at the time of this writing), so I'm going to throw in a couple of steps where you can fail miserably while setting it up. Big thanks to Paul Schaeflein who also walked the hard path and took some hits to get this to work! Although there are a couple of available blog posts out there on this issue, some of the are very sparse on the details (why?) and some even contains faulty instructions. Just to safe up on this - the instructions works on my machines and I've been able to reproduce these steps a number of times. If you have any suggestions or comments, just leave them here and I'll try to (get someone to) answer them...
So what are we waiting for, let's get the party started. I have to warn you - if you don't like certificates - stop reading!
While I will explain more in details as we move along I think it is important to have a little heads up on claims based access and Windows Live ID. First of all (passive) claims based access is based on the simple scenario where a client/user (subject) trying to access a site (also called Relying Party/RP). This RP has distributed the login procedure to one or more trusted parties called Identity Providers (IP). In our case SharePoint is the RP and Live ID is the IP and you of course are the subject. When the subject tries to access the RP, the subject will be redirected to the IP where the actual logon process is taking place. By attaching cookies to the response and redirecting the user back to the RP with a set of (encrypted) claims the RP can finally authenticate the user. For a better understanding I recommend you to read A guide to Claims-based Identity and Access Control.
Windows Live ID (WLID) will take care of the login and send back a unique ID to the SharePoint site. This unique ID is the only claim WLID will give you. (Unfortunately you cannot get the correct e-mail address or the name of the user.) SharePoint will first verify the validity of the encrypted security token (containing the claims) before actually starting the AuthN and AuthZ process using the unique ID as username in SharePoint. You will later see how we give access to these unique ID's.
Another important thing to keep in mind is that WLID have two "zones"; INT and PROD. The PROD zone is what you normally use when logging in to Hotmail etc. The INT zone is used for development and testing and have a completely different account database, so you need to have accounts in the INT zone to continue, more about this in a little bit. You cannot skip the INT zone, you have to register your site there first before applying for approval in the PROD zone.
The steps provided here is only for the INT environment. For PROD it is basically the same and the post is long enough as it is...
Registering the site
Before even starting to configure the SharePoint site we need to register our site for usage with Windows Live ID. This is done using the Microsoft Service Manager web application located at http://msm.live.com/. You log in to this service using you normal (PROD) Windows Live ID account.
In the left menu click on Register Your Site (1). This will bring up the Register Your Site page where you should enter the name of your site, use a descriptive name (2) and the DNS Name of your site (3). The DNS Name is important! Here you must specify a DNS Name, which we will later change into a URI, or rather URN. Write something random such as
The DNS Name will be used as a SAML Audience when the security token is sent back and it will be verified by SharePoint. According to the SAML specification the audience must be a URI (a URN or URL). If you use a URL then WLID will for some reason remove the protocol from the audience when sending it back to the RP and SharePoint will throw an exception ([InvalidOperationException: This operation is not supported for a relative URI.] System.Uri.GetLeftPart(UriPartial part)). This might change in the future.
Finally you have to specify that you will use Windows Live ID (4). Click Submit to continue.
You will get a confirmation screen. Click Yes to confirm and proceed to the next step
After a few seconds you will be presented with the results. If anything goes wrong you need to go back and edit your registration accordingly - but it shouldn't if you followed these steps.
Click on the Go to Manage Your Site link. In the drop-down (1) select the site that you just registered and then click on the Modify Editable Site Properties link (2).
The next screen allows you to edit the properties of the site. First of all check the Show advanced properties check box to enable more options.
First we need to rename the Domain name (1) and set our real domain name to use. Then we need to replace the dummy DNS name (2) with a URN, in this case I use
urn:wictorslivesite:int. Remember not to specify a URL, it just won't work as of now. The third thing to edit is the Default Return Url (3); this must be an HTTPS url pointing to the
/_trust/default.aspx page, for instance
https://extranet.corp.local/_trust/default.aspx. This is the URL that the IP will post back the results to. Finally we have to edit the Expire Cookie URL (4). Just fix the URL and never mind the actual page (you can implement such a page if you feel to at a later time).
Then scroll down a bit on the page until you reach Override Authentication Policy, this step is crucial. Select MBI_FED_SSL in the drop-down. And when you're done click Submit (at the top of the page).
Verify and confirm your changes by clicking Yes on the next screen. Take a screenshot and/or notes all these changes.
That's it. Your site is now configured. Actually you can configure a bunch of more features here - but stick to these as of now...
Let's move on to the SharePoint Server.
Claims based authentication uses certificates for encryption and signing and you have to trust the certificate of the IP on your SharePoint servers. The following steps must be done on all WFE's in the farm.
To get the IP certificate; browse to federation metadata URL: https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml (this is for the INT zone). Then copy the inner text from the first X509Certificate node. Open up the Notepad application and paste the text and then save the file as LiveID-INT.cer. Make sure that you only get the inner text of the element.
Now you have the certificate in a file and you need to import it to the correct locations on the SharePoint Server(s). It is actually required to be stored locally on three different locations. Open mmc.exe and add the Certificates snap-in. When you select to add it you must first select to use the Computer Account to manage the accounts for and select to use the Local computer as computer to manage.
Expand the tree until you reach SharePoint > Certificates then right-click on the node and Select All Tasks > Import...
In the import wizard that appears locate the LiveID-INT.cer file you just created and then click Next > Next > Finish. That's the first one.
Repeat this procedure for the Trusted Root Certification Authority and Trusted People. Don't worry if you don't have a Certificates sub-node. It will be created when you import the certificate.
Now we're one step closer and it is time to get dirty with some PowerShell. You could of course have done this step using PowerShell, but I leave that for another crafty blogger to show how... Just remember to do this on all WFE's!
Create the STS provider
To create the Trusted Identity Token Issuer, that we will use to configure as the login provider for the Web Applications, we fire up PowerShell. This step will not be that "visual" as the previous ones, since none of these commands can be run using the standard SharePoint user interface. I guess it's just a matter of time until someone makes a neat add-on with these simple commands...
I'll give you the script first and then explains all the involved steps:
1: asnp microsoft.sharepoint.powershell 2: $realm = "urn:wictorslivesite:int" 3: $certfile = "C:\Temp\LiveID-INT.cer" 4: $rootcert = Get-PfxCertificate $certfile 5: New-SPTrustedRootAuthority "Live ID INT Root Authority" -Certificate $rootcert 6: $emailclaim = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "http://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming 7: $upnclaim = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" 8: $authp = New-SPTrustedIdentityTokenIssuer -Name "LiveID INT" -Description "LiveID INT" -Realm $realm -ImportTrustCertificate $certfile -ClaimsMappings $emailclaim,$upnclaim -SignInUrl "https://login.live-int.com/login.srf" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
The first line just loads the SharePoint PowerShell Snapin (1), asnp is a shortcut for Add-PSSnapin and saves you a cpl of keystrokes. Then we set three local properties; realm corresponds to the DNS Name (that is the URN), certfile points to the location where you saved the LiveID-INT.cer file and the rootcert is the certificate loaded in as an object.
Make sure not to make any typos in the claims URN's - been there, done that!
Then we add the certificate to a SharePoint trusted Root Authority, using the New-SPTrustedRootAuthority cmdlet. You can verify that it is correctly imported by going to Central Adminitration > Security > Manage Trust:
Then we need to create two claims mappings; one for e-mail (line 6) and one for the identifier (line 7). The claim mappings defines how the incoming claims are mapped to the SharePoint tokens. These two claims are then sent into the New-SPTrustedIdentityProvider cmdlet (line 8) and here is where the magic happens. This cmdlet creates a new trusted identity provider with a name and description, we instruct it which claims mappings to use and which claim is the identifier claim. We are also specifying the URL for the WLID (INT zone) login page.
Once these commands are executed, we are ready to head on over to the UI and create a Web Application. By all means, if you prefer to do the rest using PowerShell, feel free to do it.
If you are fiddling back and forwards using different registered Live ID services, you can switch the Realm using the DefaultProviderRealm property of the Trusted Identity Provider object (authp). Don't forget to call Update() on the object... You can only have one provider for each service, even if the realms differ.
Create the Web Application
Fire up Central Administration and go to Application Management > Manage web applications. Click New to create a new Web Application.
First of all you need to select to use Claims Based Authentication. Then enter a Name for your web application, use the port 443 (SSL) and (in this case) configure the host header to match the domain name that you entered while registering the WLID service. Just standard stuff so far.
Under Security Configuration make sure that you select Use Secure Sockets Layer (SSL).
Under Claims Authentication Types leave Windows Authentication enabled if you like, but make sure to check Trusted Identity Provider checkbox and then check the LiveID INT provider, the one we created using PowerShell.
Once done click OK to create the Web Application.
We're almost there just a few steps more...
Create the Site Collection
Once the Web Application is created you can directly click on the Create Site Collection link. Enter name and description for the site, and also specify which template to use.
Now it is time to give some permissions to this site collection. Assume that we did not select any Windows Authentication when creating the Web Application, then we can only add Live ID users, right?
If you don't have a WLID account in the INT domain it is time to get one now. Open up a new browser window. Go to https://accountservices.passport-int.net/ and sign up for a new account or sign in using one of your existing INT accounts. (Stability of the INT domains are not 100% :-). When you have signed up or logged in click on Credentials and then View your unique ID.
You will now see a screen with your unique ID; write it down, copy it or remember it...
Close the browser and return to the Central Administration where you started creating a Site Collection. Now paste or write this unique ID and append
@live.comin the Primary Site Collection Administrator. But, make sure to convert all characters to lowercase, otherwise you will not be able to log in later:
Then click OK to create the Site Collection.
Before browsing to the site we need to make some final adjustment in the IIS. To be precise we will add a certificate to the site. You can use a certificate that you have acquired for your site or when testing just use a Self-Signed, which I will show you here.
To create a Self-Signed certificate start the IIS Manager and select the server. In the Features View double-click the Server Certificates module.
Then click Create Self-Signed Certificate in the Actions bar to the right and follow the instructions. Mostly next-next-finish.
The final configuration is to use this certificate on the Web Application. Choose the Web Application you created in SharePoint in the IIS Manager (1), then click on Bindings (2), select to edit the only binding you have (3) and choose the SSL certificate you just created in the drop-down (4). Click OK and close everything down.
That's it! Let's see how it behaves...
Taking it for a test drive
Now open up a web browser and go to the web application you have created using the domain name you specified when creating it, make sure to use https. You should see the standard warning in the browser that the certificate is not valid (add it as trusted if you want to skip this warning in the future), otherwise just click the continue link.
If you have several authentication providers you will see the new SharePoint 2010 Sign In screen with a drop-down where you can choose the authentication provider you would like to use to log in with. If you only have one, in this case the WLID, you will be redirected to the WLID Log In screen - the same will happen if you select LiveID in the drop-down.
If you get an error stating We're unable to complete your request, like below, you most certainly have not used the correct Realm when creating the trusted identity provider using PowerShell. Make sure that the Realm and the DNS Name in the Live ID Service Manager are exactly the same, case sensitive and all.
The Windows Live ID sign in screen should look as expected, just the same as logging in to other Live ID services. Enter your INT username and password (remember this is still the INT zone).
If you remembered your username and password correctly you will very soon see the beautiful SharePoint 2010 scenery:
Note that your username and display name will be exactly the same as the unique id you have for that user. How to fix this is scheduled for a later post :)
So, there you have it. It's a handful of steps to complete and you have to make sure not to mistype anything. I will continue this series with some more info that could be of great use when setting this up - hopefully not as long as this one though...
Windows Live ID Authentication for SharePoint is a project that has been developed for some time for the upcoming Swedish SharePoint Community Site, which will be an awesome site with some really cool features of which this is one.
I have previously tried some of the available Windows Live ID providers for SharePoint that are out there on the market and the best (previously) one is the provider from the Community Kit for SharePoint, originally developed by Keith Bunge. It has a great basic application design, but had some things that annoyed me and some things I wanted to change, therefore I created my own version, with the CKS version in mind, which I hope that you find useful.
There are a lot of features in the provider and I have some even greater plans…
- All configuration done through the SharePoint web interface; Central Administration or in the sites
- Forces users to register once registered
- Profile information that is more community-like
- Profile images
- Web Parts for displaying last logged in, last registered and all users.
- Users can be locked
- Approval of users can be turned on
- Profile changes can be published to announcement lists
- Four predefined roles for permissions management
You can download it now from http://spwla.codeplex.com/, you will also find a document with installation and configuration instructions. There are a few known bugs on which I work on, but if you can spot them or others, please report an Issue on the CodePlex and if you have any suggestions I really like to hear them.
In upcoming posts I will dig into some of the features a little bit more, but until then here are some screenshots.
Configuration in Central Administration Logged in users menu Configuration of the Live ID enabled Web Application Last logged in members web part Edit personal profile Built-in Live roles