Enabling Distributed Authentication and Access Control Using Researcher Profile Systems

Nick Benik, Harvard Medical School

nbenik@gmail.com 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

Semantic Web & Linked Data is

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!

Web-wide Federated Identity Management

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 to the Rescue!

Cryptography + Semantic Web

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.