Posted by BPuhl on June 10, 2009
If you use Facebook, you might notice a box when you log in that says beginning June 12th, Facebook will allow registration of user names. If you “click here” to have them send more info, you’ll receive this in your registered email inbox:
Starting on Friday, June 12th, at 9:01pm, you’ll be able to choose a username for your Facebook account to easily direct friends, family, and coworkers to your profile.
To select your username, visit the link below after 9:01pm on June 12th:
To learn more about usernames, visit the Help Center:
The Facebook Team
So what does this mean? Well, for one thing, it means that if you’ve got a common name – or – if your like me, and you KNOW that there’s someone else on Facebook with the same name (since he and I are actually friends on Facebook), then it means that you want to “claim” your user name as soon as the application opens.
I did seen an interesting article here http://www.huffingtonpost.com/jonathan-handel/trademark-protection-and_b_213756.html about trademark registrations and how Facebook intends to handle squatters. So don’t bother trying to register facebook.com/McDonalds, you won’t have it for long if you do.
I like the very last part of that article though. There is already a recommendation for what to do, if somebody maliciously claims not only your trademark, but also fills out the forms sufficiently such that you (the legitimate owner of the trademark) actually can’t use the automation to claim it back.
Oh how much fun Identity Management can be 🙂
Posted in Babbling and Blabbering, Digital Identity, Friends and family, Identity and Access, Random Tecnical Stuff, Randomness | Leave a Comment »
Posted by BPuhl on June 9, 2009
Congratulations to all of the MSIT and Product Group members who got us this far (and let’s not forget the users!)
Posted in Active Directory, Random Tecnical Stuff | 4 Comments »
Posted by BPuhl on June 8, 2009
6 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this: https://federation.foo.com:9031/blah – notice the port 9031?
This seemed a little random, but not completely unusual since people tend to grab an available port when they want to host a test/beta site.
With a bit of troubleshooting, working with our proxy server team, etc… figured out that our proxy servers only allow SSL connectivity out to port 443, so the federation was broken. A bit of back and forth with the partner, they moved to the standard SSL port, and everything worked great.
4 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this: https://federation.contoso.com:9031/blah
Us: Hey, we’ve seen this before – we can only connect to port 443 for SSL sites, can you move your federation server to the standard port?
Reply: Sure, done – check it now
And there was much rejoicing. yeah.
Rinse and repeat this a half a dozen times over the past few months, and we’re getting pretty good at recognizing the issue. And since about 60% of our federation partners are using STS’s which are not ADFS/Geneva, this scenario is even more common.
The other day, while dancing this dance yet again, we did notice one thing though – It’s not a random port – it’s ALWAYS port 9031. Not only that, but looking back, it’s always with partners who are using Ping Federate server.
A quick search for “9031” on the Ping website, finds that a lot of their sample code uses port 9031.
Ah ha! Now I get it. It wasn’t random after all, but rather re-using the sample code to set up services. Which is a great, so now we know that when we’re federating with a partner that’s using Ping Federate – be on the lookout for port 9031.
Posted in ADFS, Digital Identity, Random Tecnical Stuff | 2 Comments »