enabling distributed authentication and access control ... · enabling distributed authentication...
TRANSCRIPT
Enabling Distributed Authentication and Access Control Using Researcher Profile Systems
Nick Benik, Harvard Medical School
[email protected] http://hackerceo.org
10.6084/m9.figshare.735903
Semantic Web
• Like the WWW but designed for to be read to by machines (and data geeks)
• Data exists in a graph format rather than column/row/table format
• Datum exists in a format that can link to other datum across the Internet
Traditional RDMS Linked Data Graph
Identity Management
• Modern principles of Identity Management track back to early computers.
• Help manage which PhD’s get to play on the shared computer system?
• Macroscopic in solution scope.
• Federation Happens - one Mega Corporation merging with another.
• Not fully REMOTELY compatible with Linked Data concepts of “Identity”.
Identity is created Identity no longer exists
The Non-Linked Data Way
Identity Management
• Reality is global and all encompassing.
• For most cases of Individual P, P only has at most 1 active Identity I .
• Internet Rule #1: The Internet Never Forgets!
• Internet Rule #1(a): The Internet Never Forgets (the Identity someone owned)
Identity is Created Identity exist but longer active
The Linked Data Way
Identity Management
• I really, really, really, hate current identity systems.
• How many online identities do you have?
• How many unique username/passwords do you have?
Identity Management
• These are not your identities!
• These logins are “specializationOf” your one true identity!
Federated Identity Management
• “Lets decentralize/share identities”…
• Microsoft, Google, Facebook, Yahoo, MySpace and 100’s of other sites agree.
• Does this actual improve things?
• YES: site operators no longer need to re-develop full authentication system.
• NO: less usernames/passwords need to be compromise to destroy your life.
• See Internet Rule #72: The Internet Is Never Happy!
OpenID Authentication Process • User tries to connect to a requested service. • The service redirects the user to their Identity Provider requesting validation. • The user logs into to the Identity Provider’s servers and is then given a
notarized message. • The user presents the notarized message to the requested service. • The service (already knowing the crypto-keys of the service) validates the
notarized message and authenticates the user.
OAuth Authentication Process • User tries to connect to a requested service. • The service redirect the user to their Identity Provider to requesting a token. • The user logs into to the Identity Provider’s servers and is then given a token
to provide to the requested service. • The user presents the token to the requested service. • The service (already registered with the service) now uses the token to gain
controlled access to the user’s data/account at the Identity Provider.
Weaknesses of these Systems
• Consolidation of vulnerability (one account to hack them all)
• Unclear access control. Use Facebook to log into a professional business site and your private status updates and unprofessional profile picture get automatically imported into your account. I once log into a social website that requires Google OpenID. My full name, profile picture and more was instantly associated (and SEO indexed) with Lady Gaga’s social media site (Backplane, Inc). [http://littlemonsters.com/nbenik]
• Many times users do not have granular security without creating multiple IDs
• Multiple IDs don’t map to a single FoaF profile. One of the promises of the semantic web gets broken.
• No CIO looking to integrate a newly acquired company is going to drop Active Directory and use Google/Facebook/etc to authenticate employees.
WebID
• Cryptographically self-signed SSL Certificates
• NO USERNAMES/PASSWORDS are ever needed!
• The Subject Alternate Name field of the Certificate to point to a URI.
• The specified URI presents the public key for the SSL Certificate.
• The working SSL connection + the matching of the public key at the URI validates that the person on the other side of the wire has ownership of the URI.
WebID Authentication Process
• Web Browser starts SSL connection using a WebID Certificate. [2]
• Server examines Subject Alternate Name field of the Certificate and gets the Semantic Web document at the specified URI. [3,4]
• The document’s public key matches the public key of the SSL Certificate. [2,5]
• Working SSL connection + matching of the public key at the URI validates that the person on the other side of the wire is the URI’s owner. [2,5]
WebID + Social Networking Websites like VIVO are Part of the Solution!
• Security needs vary by company : SSL Certificates need different strengths, expiration dates, etc. This requires different SSL Certificates by the user.
• Rules of Business #1: YOU MUST CONTROL IT!
• Business will not allow user’s to “bring their own” WebID Certificates that do not point to their own WebID server. Businesses need instant revocation capability of a certificate by deleting it’s Semantic Web document.
EWID: WebID + Enhancements
• EWID’s point to a certification URI not a FoaF profile.
• EWID certification URIs contain two specific links: Authority and Identity.
• EWID Identity links point to FoaF profiles via uni-transversible link with bi-directional validation (using new cryptographic primitives).
• EWID Authority link points to an Authority, or Authority Group semantic web document, also using the new cryptographic semantic web links.
• EWID Authority document contains hierarchy links to: Greater, Lesser and Peer Authority entities. All links are also cryptographically secure and signed by owners of both Authority documents.
• EWID Authentication occurs same as WebID but a crawl is performed across similar Authority documents until an a trusted authority is found by the EWID Authentication server.