Identity and Access Management (IAM)

Misc References

OpenID

LDAP

Wikipedia

Products

Roadmaps

Diagrams

Queue

Ruby LDAP

Stakeholders

  Intranet
Applications
Internet
Applications
Private
(Employees)
Zimbra
CS
SilkRoad
Aetna
Protected
(Partners)
n/a Basecamp
Google Docs
Public
(Anyone)
n/a www.wested.org
www.simscientists.com

Questions

OpenId Issues

Can an Active Directory be used as a OpenID provider?
From http://stackoverflow.com/questions/2453769/active-directory-as-openid-provider Yes, you can. Just host an ASP.NET web site that itself uses Active Directory authentication, and exposes an OpenID Provider using DotNetOpenAuth.
Can Active Directory interoperate with Unix?
http://en.wikipedia.org/wiki/Active_Directory

Varying levels of interoperability are possible:

  • Using standards compliant LDAP clients (but these systems may lack some features of AD).
  • Third-party vendors who offer Active Directory integration for Unix platforms, include Centrify (DirectControl), Computer Associates (UNAB), CyberSafe Limited (TrustBroker), Likewise Software (Open or Enterprise), Quest Software (Authentication Services) and Thursby Software Systems (ADmitMac).
  • Open source Samba software provides a way to interface with Active Directory and join the AD domain to provide authentication and authorization
  • Microsoft Windows Services for UNIX product.
  • Peer-to-Peer using 389 Directory Server (formerly Fedora Directory Server) or Java System Directory Server, which can perform a two-way synchronization with Active Directory and thus provide a "deflected" integration with Active Directory as Unix and Linux clients will authenticate to FDS and Windows Clients will authenticate to Active Directory.
Redirection vs. Cookies
http://stackoverflow.com/questions/22015/openid-as-a-single-sign-on-option

Seamlessly logging in with OpenID requires automatic (unverified) redirection between domains.

That makes the OpenID server a 3rd party. This can cause cookies for the OpenID server to be rejected if you turn off 3rd party cookies and your browser strictly follows the Unverifiable Transactions rule in 3.3.6 of RFC2965.

An example of this is Opera. If you turn off 3rd party cookies (by setting the global to "Accept only cookies from the site I visit"), you can't log in with OpenID because the server script you submit to automatically (without your interaction to approve it) redirects you to the OpenID server and the OpenID server does the same to get you back.

But, you get lucky in Firefox, IE and Safari with their corresponding blocking of 3rd party cookies because they violate RFC2965 in multiple situations.

Having to use OpenID in this case does a disservice to more compliant clients.

As a workaround, in Opera, besides accepting all cookeis, you can goto tools -> preferences -> advanced -> Network and turn off Automatic Redirection. Then, you'll be able to verify and click each link you're redirected to and the cookies won't be rejected because the transactions are verified.

It should also work if you keep Automatic Redirection on and both servers generate a page with a link for you to click on so you can verify the transaction. But, there can't be any automatic redirects anywhere.

Logging in with just a username and password where you're only dealing with first party cookies would be much better in this case.

OpenID is still cool though and I guess Opera just needs an option to allow unverifiable transactions between SO and your OpenID server so that you can use "Accept only cookies from the sit


OpenId Outsource Providers

From http://openidexplained.com/get

Name Ease of use Security Remembers information Multiple profiles Anti-phishing measures Password protected
AOL/AIM 3 4 Yes
Blogger 9 4 Yes
ClaimID 9 4 Yes Yes
GetOpenID 7 4 Yes
Google 7 4 Yes Yes
LiveJournal 9 1 Yes
MyOpenID 8 9 Yes Yes Yes Yes
MySpace 6 1 Yes
Sxipper 7 8 Yes Yes Yes Yes
VeriSign 7 7 Yes Yes Yes
Vidoop 8 4 Yes Yes Yes
WordPress 5 1 Yes Yes Yes
Yahoo! 10 4 Yes Yes



Popular Press Articles

Are mandated password changes a good idea?

Users hate them. They're a massive headache to network administrators. But IT departments often mandate them nonetheless: regularly scheduled password changes — part of a policy intended to increase computer security. Now new research proves what you've probably suspected ever since your first pop-up announcing that your password has expired and you need to create a new one. This presumed security measure is little more than a big waste of time, the Boston Globe reports.

Microsoft undertook the study to gauge how effectively frequent password changes thwart cyberattacks, and found that the advice generally doesn't make much sense, since, as the study notes, someone who obtains your password will use it immediately, not sit on it for weeks until you have a chance to change it. "That’s about as likely as a crook lifting a house key and then waiting until the lock is changed before sticking it in the door," the Globe says.



What's Next?

blog comments powered by Disqus