Running with Elevated Privileges - Latest Comments

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Pilsen — Mon, 10 Jun 2013 19:39:27 -0000

Should have taken a closer look to the hover.
Thanks a lot!

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Danny Jessee — Fri, 07 Jun 2013 07:09:01 -0000

That behavior is by design. Unless you develop a custom claims provider, the people picker is "dumb." It's not actually looking up or "resolving" what you type in, it's just allowing you to assign permissions to values for any of the 5 claim types you mapped with the New-SPClaimTypeMapping cmdlets: emailaddress, name, AccessToken, name, and nameidentifier. If you select one of the matches from the people picker and then mouse over it, you should see which of the 5 claim types your selection maps to (so you should never have to grant access to all 5). Hope that helps!

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Pilsen — Thu, 06 Jun 2013 20:55:24 -0000

That was easy!, however it does have an odd behavior.
Say I want to add 'myfacebookaccount@provider.com', when I look for it in the people picker, it will always return 5 matches, one of those is the actual account, which will allow the user to log in, the other 4 I don't know what they are.. so in order to make sure that myfacebookaccount@provider.com is able to log in, I will have to grant access to all five matches, otherwise if I randomly pick one, chances are i will pick the wrong account and the user wont have access.

It funny how you can type any occurrence like "sdfsfsw34432" and that will still match to 5 'accounts'.

Any thoughts on this? What will be the implications of granting access to all 5 matches?

Thanks!

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Danny Jessee — Fri, 31 May 2013 06:29:55 -0000

Thanks! You can take one of two approaches. This post used a permissive approach (assuming it is a public-facing site, it makes sense to give everyone who comes in via Facebook a certain level of permissions since you don't know who all your users will be). If you DO want to restrict permissions, though, you wouldn't assign a Full Read policy the way I do here. You would instead have to specify exact claim values (e.g., email addresses associated with the Facebook accounts of the users to whom you wish to grant access). You can enter and select those values from the people picker and assign permissions to them the same way you would with other identity providers. Hope that helps!

Re: Using LinkedIn as an Identity Provider for SharePoint 2010

Danny Jessee — Fri, 31 May 2013 06:25:17 -0000

Interesting workaround. Sounds like it gets the job done. You should blog it!

As far as search goes, if Windows authentication is not selected on any zone of the Web application, crawling will be disabled and search will not work. No way around that.

Re: Using LinkedIn as an Identity Provider for SharePoint 2010

Istvan — Fri, 31 May 2013 06:16:31 -0000

Others not suggest HTTPModule method because it caues resource problems. So I write a custom aspx page and place a javascript in a master page, which check the user Name(Title) and if is number(match the regex) redirect the user to the aspx page. (and attach a query string with orignal url, so when the user click the save button, redirect to original link)

Could you try the search in the loggad on user (on that page, where only the SAML auth enabled)?

On SP2013 the search not working fairly when I disabled NTLM on the extended site.

Thanks,
Istvan

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Pilsen — Fri, 31 May 2013 01:29:54 -0000

Excellent work Danny,

It works like a charm. I was wondering though (forgive me if it is a dumb question), how can we restrict the log in to certain people. Obviously some sort of user mapping needs to happen the first time the user attempts to log in, but I am not sure how to go about it.

Any help would be appreciated

Ta
Andres

Re: Using LinkedIn as an Identity Provider for SharePoint 2010

Danny Jessee — Wed, 29 May 2013 21:43:48 -0000

Thanks, Dee! The 'nameidentifier' claim is parsed from the user's LinkedIn profile URL, which is returned by the LinkedIn API. However, it appears that the format of that URL recently changed from using 'key=' to 'id=' instead. I updated the code for the GetProfileId(string url) function in my STS code above (see line 78 in the Login class snippet) and verified that profile IDs are being correctly parsed again. Thank you so much for bringing this to my attention!

Re: Using LinkedIn as an Identity Provider for SharePoint 2010

Dee — Wed, 29 May 2013 09:38:36 -0000

Hi,

I am getting 'nameidentifier' claim as a URL not as a ID. Could you suggest what could be wrong? The URL also starts with p, instead of http.

http://schemas.xmlsoap.org/ws/... = p://www.linkedin.com/profile/v...

Weird!

PS: Great article!!

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Danny Jessee — Tue, 28 May 2013 20:12:11 -0000

Rob - you can change the display name using either the object model or PowerShell. If you want to use the object model, you could do something similar to what I did in my "LinkedInNameChanger" near the bottom of this post: http://www.dannyjessee.com/blo...

You would obviously pull the emailaddress claim value instead of the givenname one.

If you look at the comment thread below that post, you'll see someone also found some code that handles this problem in a more automated way: http://www.codefornuts.com/201...

Hope that helps!

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

justskeddy — Tue, 28 May 2013 10:15:55 -0000

Hi Danny,

After checking out a few blogs and chatting to
Microsoft themselves, it turns out the using the UID type identifier is not the best way, as SP2013 is expecting a different type of UID.

They are going to suggest it as a feature change, to make it more manageable.

In the meantime, could I possible ask one more question? I've been able to get Google integrated successfully via ACS, but the display name in 2013 is showing up as http://www.google.com/accounts... long string).

Do you know if there is a quick way to change this to show the e-mail address?

Cheers,

Rob (same Rob as above!)

Re: Using LinkedIn as an Identity Provider for SharePoint 2010

Danny Jessee — Fri, 24 May 2013 06:17:59 -0000

Good find! That has a lot of potential. I believe an HTTPModule would be the only way to accomplish this. If you try it out, let me know how it works for you. Thanks for sharing!

Re: Using LinkedIn as an Identity Provider for SharePoint 2010

Istvan — Fri, 24 May 2013 04:53:28 -0000

I find a post yesterday. What is your opinion?

http://www.codefornuts.com/201...

Thanks,
Istvan

Re: Using LinkedIn as an Identity Provider for SharePoint 2010

Danny Jessee — Thu, 23 May 2013 19:21:57 -0000

Unfortunately there is no event you can capture to update the display name automatically the first time a user signs in. You could run a script on a schedule to update the display names for new users (at least removing the user interaction part), but it wouldn't happen automatically the first time the user signs in.

Re: Using LinkedIn as an Identity Provider for SharePoint 2010

Istvan — Thu, 23 May 2013 19:09:16 -0000

Hello,

How can I make the personalization without user interaction? Thus the user log in to the portal and the Display Name automatically overwrite the ID.

Thx,

Istvan

Re: Using JSOM to write (small) files to a SharePoint 2013 document library

Danny Jessee — Tue, 21 May 2013 17:01:57 -0000

Thanks! You raise a very good point. In my actual code, I did declare those variables outside that particular function with the var keyword, but left it out of the snippet I posted here for brevity. You are absolutely right, though.

Re: Using JSOM to write (small) files to a SharePoint 2013 document library

Guest — Tue, 21 May 2013 06:55:27 -0000

Hello, i was looking for exactly such a example, good work! :)
But: in "receivedBinary" you declared lots of variables without the var keyword - this will make them to global varaibles in the current context, very dangerous and hard to debug (speaking out of experience)

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Danny Jessee — Fri, 03 May 2013 19:04:02 -0000

Thanks for the additional info. When you refer to the "UID" of the Live account, I assume you're referring to the "00000aaaaaaaa@live.com"-type identifier that is generated and not the user's actual email address, correct? If so, are there multiple entries with the same value returned by the people picker when you enter the user's Live UID? It is important that you choose the one that maps to the proper claim type (if you've mapped multiple claim types in your trusted identity provider, there will be multiple values returned here), and it has to match the claim value exactly (unless you built a custom claims provider, the people picker is not giving you true name resolution). Hope this helps!

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

justskeddy — Fri, 03 May 2013 07:08:34 -0000

Hi Danny, thanks for replying, hopefully you won't be bored with the following waffle :-)

If I apply the Full Read Policy, I can access the site. The problem is, if I then try to use an alternative Windows Live ID account, that immediately get's access too.

In terms of the setup - I have a site collection, that is extended (to a different URL) for external access.

I have set up the ACS server, and added it to both the Default zone (for my internal users) and my Internet zone (for external users on the extended webapp).

For internal users, they are authenticating using standard Windows logins (NTLM). I have had to also include the trusted identity provider in order to be able to resolve the Windows LiveID logins when adding them to the site.

Groups on the actual site - I have standard Member, Owners and Visitor group. The process that I've been following has to be go to the internal site, and then add in the UID for the LiveID account. When it resolves, I select the UPN account, and this is then added to my "Visitors" permission group.

I should then be able to access my external site, login with the proper e-mail address for the LiveID, and then get access to the site - this is where is stop working, and I get the "Sorry you do not have access".

There *is* another identity provider set-up - this was when I was using the older msm.live.com service. But this is not ticked.

When you say add in a user from the ACS provider as a site collection admin, what do you mean? If I look at current site collection owners for the internal site, both my local Windows account is added, as well as one of the service accounts (again, a windows service account).

Hopefully this gives you a better over view of my setup?

Cheers!

Rob

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Danny Jessee — Thu, 02 May 2013 18:29:15 -0000

Rob - Thanks for commenting! Hopefully I can help. How are you granting that group access to the site? Do you have another authentication provider (e.g., Windows) set up on the same site? Someone from the ACS identity provider should serve in a Site Collection Administrator role as well. (As a side note, does it work if you DO set that Full Read policy at the web application level?)

More questions than answers from me, I know, but hopefully we can get to the bottom of it. Personally, I've always set the Full Read policy since an internet-facing site would need to be accessible to any user coming in from the ACS identity provider.

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

justskeddy — Thu, 02 May 2013 12:57:10 -0000

Hi Danny,

If I already have permission groups set up within SP2013 do I still need to set up the user access policy?

I have recently used ACS to add Windows Live, and I can add and resolve users, but when I then browse and login, I get the "Sorry, this site has not been shared with you" message - despite having just added the user to the group.

Would appreciate your thughts.

Cheers,

Rob

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Danny Jessee — Thu, 28 Mar 2013 06:22:38 -0000

Yes, it can be done without Azure ACS but it requires a lot more work on your part. You need to build your own STS that knows how to reach Facebook, ensure the user has signed in there, obtain claim information from Facebook, and package and sign SAML tokens. (As you can see, Azure ACS really simplifies everything, and it's free!) If you do want to go the non-commercial route, Travis Nielsen has written up a great blog post about how to do this same integration without Azure ACS here: http://blogs.perficient.com/mi...

And yes, these solutions will work in Foundation as well.

Re: Using Azure ACS to Sign In to SharePoint 2013 with Facebook

Mohamed Ubaidullah — Thu, 28 Mar 2013 03:20:57 -0000

Danny,

Is it possible to do this without using Azure ACS? I am specifically looking for non-commercial alternatives.. Also, I assume it should work for SPF 2010 as wellL

Re: Ensure an SPUser Exists in an Application Page Within an Anonymously Accessible Site

cthree — Mon, 18 Mar 2013 05:13:11 -0000

Thanks for the reply! Ah, makes sense that it wouldn't be aware. Wouldn't want an external site to have access to the SharePoint info. We'll utilize our company's global authentication instead of the separate internal SharePoint site's authentication.

We're using the LoginName to record who last updated the data from the website. We were hoping to utilize the SharePoint site so we could leverage its user groups, and we wouldn't have to maintain that group as well as one for the global authentication. Looks like there's no way around maintaining 2 user group lists, but at least we'll get the info we need from the login. Thanks again for the help!

Re: Ensure an SPUser Exists in an Application Page Within an Anonymously Accessible Site

Danny Jessee — Fri, 15 Mar 2013 21:01:54 -0000

Hmmm...interesting problem. I assume you're using SharePoint 2010? Are you using a page viewer web part to load the external page? If so, there's really no way for that page to be aware that it is inside a SharePoint container and it wouldn't be able to get any kind of SharePoint context. If the external page doesn't require a login, what would you look to do with the SPUser's LoginName on that page?