1 / 13

User Registration System (URS) Brett McLaughlin brett@element84

User Registration System (URS) Brett McLaughlin brett@element84.com. EED DAAC Technical Interchange October 3-4, 2012 Riverdale , MD. Purpose. Centralized system for EOSDIS user registration and authentication Focused on user management Focused on authentication (not authorization)

bruno-johnston
Télécharger la présentation

User Registration System (URS) Brett McLaughlin brett@element84

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. User Registration System (URS)Brett McLaughlinbrett@element84.com EED DAAC Technical Interchange October 3-4, 2012 Riverdale, MD

  2. Purpose • Centralized system for EOSDIS user registration and authentication • Focused on user management • Focused on authentication (not authorization) • Uniform API for multiple application technologies and deployments • Primary access via HTTP REST-style interface • Client-platform neutral • Limited access through FTP • Improved metrics across EOSDIS program • Accesses, both individual and unique • Password issues (resets/failures/etc.) • Client accesses (via authenticated users)

  3. A Few Statistics • User Base (as of September 24, 2012) • ~68,200 users • 6 production application clients • ECHO, LANCE, Coherent Web, AMSR-E, EMS, GES DISC • 3 additional beta application clients • API • Second generation (2.52/3) • 35+ public service endpoints • Fully supports user administration GUI, ECHO, et. al. • Stability • 100% uptime July/August/September • All deployments are staged and staggered • Extensive logging for resource planning and analysis

  4. Architecture (simplified) • Highly Available/Highly Reliable • LDAP-based authentication • HTTP-accessible API • Web-based registration and user maintenance Web-based user maintenance HTTP-accessible RESTish API HTTP clients LDAP store LDAP proxy (via LDAP store) FTP clients

  5. Architecture (detailed) Web-based user maintenance Load balancer Load balancer HTTP clients HTTP-accessible RESTish API LDAP store LDAP store FTP clients LDAP proxy (via LDAP store) LDAP store

  6. Key Data • Application account (per client) • User accounts (per user) • User is considered unique across all URS clients • Groups • Largely used for LDAP and API internals • Not used for authorization • Application-specific data • Available in URS 2.53 • Name-value pairs retrievable by application accounts uid=echo,ou=apps uid=brett_m,ou=people

  7. Authentication Workflow HTTP client uid=echo,ou=apps HTTP-accessible RESTish API 1. Bind as app account LDAP store echo HTTP client uid=brett_m,ou=people HTTP-accessible RESTish API 2. Authenticate as user LDAP store Client URS

  8. Authorization Workflow (1 of 2) HTTP client uid=echo,ou=apps HTTP-accessible RESTish API 1. Bind as app account LDAP store echo HTTP client uid=brett_m,ou=people HTTP-accessible RESTish API 2. Request user information LDAP store Client URS

  9. Authorization Workflow (2 of 2) echo HTTP client uid=brett_m HTTP-accessible RESTish API 3. Look up locally-stored user information LDAP store echo HTTP client uid=brett_m HTTP-accessible RESTish API 4. Grant/Deny/Modify User Request LDAP store Client URS

  10. App Specific Data Workflow (1 of 2) HTTP client uid=echo,ou=apps HTTP-accessible RESTish API 1. Bind as app account LDAP store echo echo HTTP client getCustomAppContent HTTP-accessible RESTish API 2. Request app-specific content LDAP store Client URS

  11. App Specific Data Workflow (2 of 2) echo HTTP client appId:echo, postContent: { registration-date:…, executive_summary:… } HTTP-accessible RESTish API LDAP store 3. Parse/interpret returned content echo HTTP-accessible RESTish API appId:echo, postContent: … HTTP client LDAP store 4. Perform application/ business logic Client URS

  12. Client Testing and Promotion Test and promote Load balancer URS LDAP (alpha) URS API (alpha) Application (alpha) URS LDAP (beta) URS API (beta) Application (beta) URS LDAP (prod) URS API (prod) Application (prod) Servers/hosts in red are not publically accessible, and can only be accessed from other URS servers.

  13. Client Takeaways • URS holds authentication tightly • Must bind as an application account • Must register each user via valid email • Must meet NASA password requirements • URS holds authorization loosely (if at all!) • May provide optional user details • May provide application-specific data • Has no knowledge post-method call • “Do what you want with your data!” • URS prefers HTTP interaction • Limited users access URS via FTP • Go/no-go authentication decisions • 35+ HTTP-based URS interactions • Reference implementation with full HTTP examples available

More Related