Ken K – Conservation of APIs. Interfederation is

Ken K – Conservation of APIs. Interfederation is driving even further multiplication of APIs. What are the pain points? Marshaling parameters – what do you call it? What are the attributes being passed? Normalization of release of information. Building interfaces that will work. Reconcile that over 90% of users of Google don’t know what information is being released. APIs are going to invoke privacy management, so we’re going to need conservation of paradigms around that. It’s going to mean multiprotocol.  What happens if I want to interact with my colleagues in a cloud app? Re-emphasizes bilateral federation vs. multilateral federation. Feds will announce federal portal soon. MLS services have done Shib, as is health care.  APIs haven’t been worrying about strength of authentication. In the future you’ll be able to buy attribute verification services – e.g. “user has put in this street address, do they really live there?”. Presumably the more you spend the better the strength of the verification. You’ll be able to buy from the Postal Service, Google, credit card services, etc. through APIs.  Reinforces the privacy aspect – will need to make this tractable.  There are a bunch of vendors that want values of “studentness” – we will be in a position to sell that to them. We pass it among each other with no charge. What does this do to our social fabric? Steven Carmody – Brown University – Models for Managing Privacy and Attribute Release Fair Information Practice Principles – passed by congress in 1974 – Transparency, individual participation, purpose speification, data minimization, use limitation, data quality and integrity, security, accountability and auditing So why are so many places asking for so much personal data to be released? Research from Penn State – when faced with a note that says “This program will erase your hard disk, click yes to continue”, 90% of people click it. One model that might help is if the attribute release process is not part of going to actually use a service.  Abc4trust/Idemix – You download identity cards from your identity providers. Will produce trusted assertion without revealing details. You choose what source you will release the information from. Process occurs in your desktop, so the iDP doesn’t know where the credential is being used.  Privacy manager properties: Accurate; Design consistency; describe who will use the data, and what they will do with it; understandable (balance, summary vs. detail, information model), encourage reasonable answers (position in flow, timing). Leveraging Social Identities Allowing access to the other 90%. An InCommon pilot to support access by people with either Federated or Social identities. Provide application owners with a single auth framework for both types of identiies. Provide info to the application about the user with a singel interface regardless of identity type. application owner can choose which social identity providers to permit. Why? We already work with people outside our communities – applicants, parents, continuing ed/MOOCs. Other areas showing interest in working with people outside the traditional communities. All of those people have identities at one of the social/personal providers. This may be preferable to issuing campus identities to those people. However, there is NO guarantee about who is using a social account. How – Web based authentication gateway, translates authentication responses from popular “social” ID services into regular SAML 2 Assertions (consumable by Shibboleth). Allows downstream applications which only understand SAML to easily utilize social IDs. Maps attributes. Works great for guest authentication. Typical use is “pick and choose” among the external services. Very powerful combined with an invitation service like that in Grouper. Consent screen at Social Providers akss users to release attributes to the gateway. Pilot gateway available since Fall 2012, but will end. 2nd Pilot underway, run by Cirrus Identity. Can be used to access I2 Spaces Wiki and InCommon Federation Manager App, currently only supports Google. Next phase – looking to expand use and use cases, require definition, testing during summer 2013, campus participants being identified, hope to have services available to InCommon members for Fall 2013.  USC’s OAuth Recipe: oAuth + Enriched Identity Data + Central Authorization – Brendan Belina Benefits of Using OAuth (Social Providers) – extend USC services to greater populations; password related issues addressed by OAuth providers; reduces barriers to adoption. Chalenges: Different versions of OAuth with different capabilities; Inconsistent and unpredictable attribute release; Attributes required for applications may be missing; Identity is self-asserted – potential risk to applications; user may use multiple OAuth providers, leading to login confusion and multiple identifiers; OAuth providers come and go, leading to potential ;loss of identifier persistence; how to revoke an OAuth Login?; Authentication without Authorization What is needed: Allow multiple OAuth providers per identity and the provider should be transparent to the service – addresses problem of user using multiple OAuth providers, addresses problem of deprecated OAuth providers; Deliver a standard attribute set regardless of OAuth provider or version for compatibility with applications; Provide consistent user attribute values to services; Externalize authorization to apps to reduce risk and allow revocation; support for both Just-In-Time provisioning and ETL provisioning.

Benefits of self-registration: registry provides single place for meantenance of user attributes; opportunity to enrich data released by OAuth providers to meet requirements and provide consistency; allow creation of persistent identifiers for use across institutional services; Opportunity to provide linking to multiple OAuth providers to address continuity; ability for user to unlink an OAuth provider or credential; Registry entries can be used for ETL provisioning and authorization to services. 

Scotty says you should use OpenID Connect for social authentication instead of OAuth.

CSG Spring 2013 – OAuth & Web Services

University as Platform – Jim Phelps, U Wisconsin Madison

In conversation with Undergraduate Advising, found that they have to use an average of 7 tools for every task they want to accomplish when talking with a student. They spend 40% of time navigating systems to perform a task, 40% teaching students how to use the systems, and 20% of their time doing high value advising. 

Platform principles: resusable, transparent, leveraged, consistent, fiscally efficient, drives agility and innovation.

Second use case – the curricular hub. Spent a lot of up front time building it, but then requires very little reinvestment afterwards. Now have 27 different consumers, all getting the same answers. 

Web Services, Authorization and the API Economy – Scotty Logan, Stanford

Data extracted from programmableweb.com – which doesn’t have an API. 

About 9k APIs registered – straightline log chart since 2005. Mostly REST, SOAP coming back a bit. API Billionaires Club: twitter, google, facebook, netflix, etc.

90% of Expedia’s business is through APIs, half of Salesforce’s access is through the APIs. 1.1 million requests/second on S3.

Drivers: Mobile, cloud, social, desire to be open, competitor has an API

We have a dysfunctional relationship with the cloud – we’re consumers of APIs, and sometimes we produce APIs, but not consistently or on a huge scale. Who allows the cloud to push and pull data? Who allows mobile apps to push and pull? The mobiel app economy relies on the API economy. How well do your apps work without a network? The Internet of Things relies on the API economy. 

API Value Chain – App user->App Store->App->App developer-> world of APIs-> API-> API Team-> Internal systems. App developers are kingmakers – so they’re the ones you have to get APIs to. 

Web Services – SOA is dead – long live services (Anne Thomas Manes, Gartner). 

SOAP or REST? REST is more popular now, means more tools and libraries, examples, design/dev experience. SOAP uses HTTP, REST is HTTP.

Authorization – how does a person allow one appt to access their data in a different app? Shibboleth (SAML) is great if there’s a browser involved. How do you authenticate if there’s no app? OAuth + REST – Designed for REST-like APIs. Like REST, OAuth leverages HTTP features and response codes. 

Allows a client application to ask a user for restricted permissions to act on their behalf / access their data in another system without exposing credentials.

OAuth authenticates apps, not people. OpenID Connect authenticates people and is built on top of OAuth 2.

OAuth 2.0 vs 1.0/1.0a

OAuth 1 required signatures – harder than it looked. OAuth 2.0 relies on SSL/TLS – additional RFCs for signatures, JOSE specs for signed/encrypted tokens. 

API Evangelism and support at Stanford – Goal is make it easier to create and deploy APIs and to find and user APIs “the right way”.

In the beginning – helped a few groups create basic APIs. Scott & Bruce as API evangelists – please make APIs, please make them RESTful, please use OAuth.

Med School CAP System – Community Academic Profiles – expanding to all faculty and staff. Other apps want data from CAP – “we’d like help with an API!” – two day REST design session with vendor. Investigated their API management tool – concerns about integration, cost. They wanted SAML – AS, token attribute passing, scope approved, rate limiting, API console, distributed ownership/control, workgroup integration (groups).

Found a few open source API management tools – big bloated unfamiliar framework or obscure implementation language or no OAuth 2.0 support.

They’re rolling their own – three pieces: OAuth Authoriztion Server; API Proxy/Gateway; 

Using CloudFoundry’s UAA, CLient Credentials flow available now.

Developer portal – probably Drupal, wil integrate with OAuth AS.

Federated OAuth is possible.

Web Services Gone Wild! Mojgan Amini, UCSD

Users were happy with their green screens – then came web applications, first with Perl then with Java. Had users using web apps and others using green screens. They centralized common services, giving birth to their middleware. Every new technology got wrapped into the middleware, which got very bloated. Attended 2006 Gartner Web Services Summit – SOA is the wave of the future. Churned out 2000+ web services! Lesson learned: a little more effort on governance up front would be a good thing. Then created a good set of web services that were reusable that were heavily used – starting with commonly used public services. Then started talking with admin users who wanted real time data over web services – provided a select set of authorized services for their purposes. Put them in a good place for launching mobile apps when they were needed. 

Still have Cobol, Perl, and Java apps along with 2000 base web services. Moving to a Red Hat middleware solution. Hoping to address self-service campus web services. 

Student Developers, Web Service APIs, and OAuth – Mark McCahill, Duke

Two cautionary tales about what can happen with student developers, web APIs and how OAuth can maybe help.

Duke launched Innovation CoLab – effectively a long format “hackathon” – student dev teams compete to identify and address campus needs, in hopes that useful apps will emerge along with more insight how to support the institution. Has pushed a bunch of changes within OIT because students want to move fast. 

Planning for CoLab – how can we enable student dev innovaation – infrastructure (easy): on-demand VMs with pre-installed application stacks for student servers (60 different images using BitNomi); self-service Git repository + bug tracking. Enterprise data in easy-to-use form for mobile apps and alternate user interfaces (harder). What data to they want? In which formats? SOAP+WDLs? XML-RPC? REST + JSON? The last won – students didn’t touch the others. 

Impedance mismatch between what students want and what IT staff are used to doing. Enterprise developers are used to servers and app stacks hand crafted by artisan system administrators. Enterprise devs use Java frameworks etc. Student developers want on-demand PPAS services such as Heroku and software ecosystems such as Node.js, Ruby-on-Rails, JSON, REST, curl, screen scraping.

CoLab; Note Cheese – Sharing class notes is a good thing; you don’t know everyone in your class and you don’t know who took good notes. Might end up with something liek Quora meets Piazza with class notes. Why make users type in their class schedule? Devs can’t get class schedules via API, so they asked for NetID and PW, then screen scraped the classes. 

Lesson: OAuth opt-in and informed consent to access individual class enrollment? Allow students at least some access to Shibb SP signup tool – policy now is that students can’t get SPs, so need to change that. Provide pre-built shib along with API stacks.

CoLab: Hack Duke – Enterprise via REST – read-only REST access to everything. Live drill-down navigation of the APIs: classes, terms, course evaluations, departments. Event calendar, map coordinates, LDAP directory via REST.  Available on GitHub. Backend is MongoDB, nodeJS front end. a fork of openworld. Some concerns are expressed – controlled access to sensitive data? All students can view course evaluations, but should the public see this? Frequency of updates? Data validity? departments offering courses <> all departments. 

Lessons: if you don’t provide enterprise data in easy-to-use forms, the students will do it anyway. read-only REST + JSON is the way to roll. Realtime browsable catalog of APIs (requiring an API key). OAuth for non-toxic user opt-in for release of data to applications, Expectation of live data for realtime course registration decision making. 

http://www.hackduke.com