- The 10th annual TechExpo will be held on April 7th at the Washington Duke Inn.
- Approval of Minutes: The minutes from the January 23rd ITAC meeting were approved as written.
II. Agenda Items
4:05- 4:30 – Dance 308/ECE 364/ISS 376/THEATRST 364 - Live Processing & Live Art: Performance and Technology: Thomas DeFrantz, Martin Brooke (15 minute presentation, 10 minute discussion)
What it is: Dance 308, cross listed with Electrical and Computer Engineering, Theater Studies, and the Information Science and Studies program, extends work from the Bass Projects initiative to integrate interdisciplinary work in practical engineering, live art, contemporary performance and cultural and performance studies. Students in the course are working in the Bass Project laboratory to combine the manipulation of data-intensive live processing with the making of live art works.
Why it’s relevant: This workshop is an exploration of technologies embedded in performance: robots, media, computer interfaces. Students create performance projects and discuss theoretical and historical implications of technologies in performance. Thomas and Martin will provide an overview of the class.
Arts Intersecting Technology: For the past 5 years, Thomas DeFrantz, Professor of African and African American Studies and Dance, and Martin Brooke, Associate Professor of Electrical and Computing Engineering, have been teaching a class called Performance and Technology which currently focuses on visualizing energy through performance. The class brings together a diverse group of students from dance, electrical and computer engineering, information science and theater studies to introduce them to the connection between art and engineering. It introduces students to basic theory and history around visual performance and live art, exposes them to contemporary artists working in this area and gives students the opportunity to engage in making objects that interact with performance and movement. The class uses technology such as Isadora (digital media software) and Arduino microcontrollers (technology used for sensing and controlling objects) to create objects that interact with performers.
The interdisciplinary class of approximately 30 students challenges its students to work outside their areas of interest and comfort. Engineering and science students might be challenged to communicate through dance and art while dance and theater students might be challenged to work with technology and code. Together they are able to create a successful interface between technology and performance.
Questions and Discussion
Question: Are engineers forced to move and dancers forced to create technology?
Answer: They are very clear that everyone will be involved in dance and in technology. There are between 25-30 students in the class. The class fills up, however, there isn’t a huge waitlist. Both sides are a little bit uncomfortable at first but this usually only lasts a few weeks.
Question: Is it a pass/fail course?
Answer: The students are evaluated on engagement. They are evaluated the same way students in a design class are evaluated.
Question: Are there any areas that could be improved from a technology standpoint?
Answer: The network performance can be intermittently degraded. Technology upgrades, both software and hardware) can present problems when they do not align.
Question: How do you define success?
- recognition that their work could lead to developments in industry
- engineers becoming interested in performance and vice versa - solving problems while taking elegance into consideration
- students thinking outside the box
4:30- 4:50 – API Catalog Go-Live, Richard Outten, Judy Heath (10 minute presentation, 10 minute discussion)
What it is: OIT has begun a soft launch for the Duke API Catalog. The catalog is a listing of Application Program Interfaces (APIs) available to the Duke community to integrate various kinds of Duke Data with web or mobile applications through well-defined programming procedures. Richard and Judy will provide an overview of the project, along with additional service rollout information related to testing, feedback, and finalizing the request process.
Why it’s relevant: An Application Program Interface (APIs) is a set of routines, protocols, and tools for building software applications. An API specifies how software components should interact with each other and are used when programming graphical user interface (GUI) components. Back in 2013, The Common Solutions Group discussed how our institutions might better make APIs available for general use. Duke has since been working to create a universally accepted API catalog.
What Are APIs: APIs (Application Program Interface) allow users to interact with applications at code level. With the adoption of the internet, this has increased the use of web service APIs, allowing smart devices and computers to connect to a server and download information. During the development of the recent version of DukeMobile, APIs were developed so that DukeMobile information could be available for use by developers at Duke. Currently, the APIs are available on an OIT hosted API developer console called Streamer (https://oit.duke.edu/what-we-do/applications/streamer).
Advantages and Disadvantages of Using APIs: There are several advantages and disadvantages to using APIs.
- Interoperability - HTTP(S) is widely used.
- Reusability – data can be reused across multiple applications.
- Consumer friendly – results are text based and easy to analyze.
- Near real-time – there is a reduced need for copying data.
- Inefficient - HTTP(s) is widely adopted but it is an inefficient protocol. There are more efficient protocols but they aren’t as widely adopted or aren’t as easy to use.
- Security - protecting data so that the right people can access the right data at the right time.
API Catalog Soft Launch: DukeMobile brought to light the need for APIs and the need to make APIs available across Duke using a more robust platform. OIT has been developing a new site called API Catalog (https://api-catalog.oit.duke.edu/. The catalog showcases the APIs available in OIT and across Duke. Most of the APIs contain public data but there are some that require users to register for an API key.
The current APIs available on the site for the soft launch include: 25Live (Co-Lab), Curriculum, Directory, ePrint, ePrint (Co-Lab), Events (Co-Lab), Events Calendar, Identity (Co-Lab), IT Alert, Libcal (Co-Lab), Places and Scholars.
Candidates for future APIs include: DukeCard (transactional, access, laundry, peer to peer payment), parking (real-time parking lot information), Sakai (grade push updates), wireless access point data (see how many people are on an access point), opt-in schedule sharing and maps data. We expect that the popularity of APIs will grow even more as interest in Internet of Things grows.
Future Considerations: As we move forward with the soft launch, OIT will be taking the following considerations into account:
- How do we protect this data and who can access it?
- Is there any liability associated with providing or using APIs?
- Is the data accurate and reliable?
- How do we prevent less experienced programmers from impacting the health of our servers and services (Kong – an open source API management tool)?
- How do we ensure the data is maintained, including documentation (data stewards)?
- What data do people want?
- Who owns the data?
- How do we handle data changes within the API?
- How do we handle version control?
Questions and Discussion
Question: How do we prevent misuse of the data?
Answer: That will always be a risk but we can minimize the risk with data stewards.
Question: Do we know who is down-stream dependent on the data once the API is released?
Answer: We will have contacts for the APIs that require an API Key. We won’t for APIs accessing public data. We could consider a public registration process. We could also leave previous versions of valid/working APIs on the site so that they don’t break down-stream processes.
Question: Can we capture the source IP address from the computer making the API call?
Answer: Yes. That could also be used when trying to investigate issues.
Question: How long will the open source API management tool Kong meet our needs?
Answer: Kong just had a major release with some very nice features. It has great performance. It is a light-weight option and doesn’t force you to purchase major architecture. It has a lot of flexibility. However, we might run into problems if we don’t have someone to manage Kong.
Comments: We have API access to DukeCard financial data that could be placed behind Kong giving us the ability to capture data in near real-time.
Question: Sakai has a robust API catalog. Who do I talk to get my APIs behind Kong?
Answer: Kong is not ready yet, but those APIs can added to the development environment. Contact Judith Heath who is the program manager.
4:50- 5:15 – Shibboleth Changes, Mary McKee (15 minute presentation, 10 minute discussion)
What it is: Shibboleth is among the world’s most widely deployed federated identity solutions, connecting users to applications both within and between organizations using their home-institution credentials (ID and password) for authentication. It provides a Single Sign-On capability (based on the configuration or many applications to accept that standard set institutional credential) and allows applications and authenticated websites to make informed authorization decisions – deciding whether a particular authenticated user is permitted individual access of protected online resources. Mary will discuss Duke’s summer initiative to introduce a new login page design, some additional multi-factor authentication (MFA) options and requirements, and increased visibility/choice about what personal information is being shared between centralized login services and affiliated sites.
Why it’s relevant: These changes will affect everyone who uses NetID or OneLink sign-in at Duke and provide service owners with new options for interacting with user data
Redesign of Sign-in Pages: OIT is refreshing the Shibboleth login environment this summer. There won’t be any major changes in functionality or data elements. The main changes will include:
- standardizing vocabulary from “Advanced Verification” to “Multi-factor Authentication” – most of the Duke community is now aware of the term multi-factor authentication,
- moving “forgot your password?” link next to the password field, and
- increase the duration of “Remember this device” from 12 hours to 72 hours. There are a few instances when “Remember this device for xx hours” doesn’t work. We are reevaluating this functionality to make sure it is working as intended which is based on device and browser. The functionality (when it works and when it doesn’t) will be better communicated to users.
In addition to these changes, OIT is evaluating adding functionality to default to a preferred multi-factor authentication option. If approved, it might be added after the summer release due to time constraints.
Questions and Discussion
Question: How will we communicate these changes?
Answer: These changes will affect everyone who signs in with Shibboleth. We’ve been working closely with OIT’s communication department to broadly disseminate information on the changes using the communication channels available including a notice on the sign-in page prior to the changes taking place.
Question: Why was 72 hours chosen for “Remember this device”?
Answer: That was a comfort level from a security standpoint. It was a good compromise without having it too long while recognizing that 12 hours was too short.
Location-based Multi-factor Authentication Policy: We will be introducing new self-service options and the ability to apply MFA requirements based on location. This will be an extension of the current service-based policy, offering increased granularity based upon being on or off the Duke network. The chart below details the proposed policy when MFA will be required
|Off Duke Network||Faculty/Staff||Box, Webmail, Sakai|
Questions and Discussion
Question/Comment: Why if we generally advise against conveying sensitive or restricted data via email would we require MFA for mail, when doing so would seem to convey a tacit approval that sensitive data can be communicated via email?
Answer: In reality, we cannot have confidence that sensitive information isn’t being sent over webmail and there are numerous cases where even despite our best guidance to the community, such information is being sent via email. The proposed policy to require MFA for webmail is only for off-Duke network webmail. MFA will not be required for smartphone hard client access or access when on the Duke Network. We are very interested in email encryption and have been talking to our email vendor about this option.
Question: How long before MFA is required for everything?
Answer: As people become more comfortable with MFA we might look at making it mandatory for any Shibboleth-authenticated site but there are no plans to do so at this time.
Consent-informed Attribute Release (CAR): Whenever someone logs into a Shibboleth-authenticated Duke website, identifying information is passed between Shibboleth and that site. They can tell the site everything they know about that person, tell them only the information that is needed to verify that they are who they say they are or tell them nothing at all. There are two considerations in this exchange of information: what is the minimum amount of information the receiving site needs to know about this person and has the person consented to this information being exchanged.
Consent-informed Attribute Release (CAR) will provide the structure to ensure that both considerations are taken into account. CAR will define institutional policies on who should be holding and receiving data while taking into account the user preferences. CAR is being developed partially at Duke and also in conjunction with TIER and Internet2.
How It Will Work: Users will see an “intercept screen” the first time they log into a Shibboleth-authenticated site. The screen will detail which information from their Duke record is being requested by the service they are logging into. After reviewing the information being requested the user can choose to opt out of releasing the information or accept and continue. By default, the CAR screen will only be shown once per Shibboleth-authenticated site; however, the user can request to see it during the next log in. Self-service will also be available so that users can review history and change preferences.
CAR Pilot: In May, OIT will be piloting an IT suggestion box application that will give users the option to consent to the release of their identifying information (attributes). If they choose to suppress their identifying information and continue with login, only their affiliation will be released.
Question: Can more information on the attributes and why they are being requested be included on the log-in page.
Answer: We probably won’t be able to have this for all 2,000+ sites for the initial rollout due to time constraints. We could have more information for a set of common attributes such as NetID, UniqueID and other public directory information. In addition, we are requiring strong labels on attributes.
Comment: It would be helpful to have a checkbox on the Shibboleth login page that will take you to the Consent Manager so that preferences can be easily reviewed.
Deployment Plan: There will be a phased deployment plan over the next four months for the redesign of sign-in pages, MFA changes (location-based policy) and CAR.
- April- Introduction of OneLink registration moving to new design
- May – Pilot of CAR for OIT Suggestion Box app – invite to ITAC to test and feedback
- June – Introduction of opt-in location-based MFA
- July – Most user-facing changes will go live including the new sign-in page, CAR prompts, and MFA requirements
Users can expect to see 3.4 (median) CAR login screens per week after go-live. They will only see the login screen once per site unless they request to see it again at the next login.
5:15- 5:30 – User Centric Metrics for Emailing and Networking, John Board (10 minute presentation, 5 minute discussion)
What it is: Working with my Master’s student Song Yang in Electrical & Computer Engineering (ECE), we have created a number of tools for measuring the quality of the experience of end users of Duke’s email system (delivery times for messages with and without links and attachments) and wireless network (network connect times).
Why it’s relevant: Building on academic work from our colleague Professor Kishor Trivedi in ECE, we can demonstrate that many monitoring tools used internally to IT systems fail to capture the end-to-end experience of users of the complete system. All components of a complex, multi-stage system (such as Duke’s email environment) can report that they are individually healthy, but users can still be having a poor experience. Song’s tools help us keep an independent check on the performance of Duke systems, and they have helped identify and diagnose problems that have resulted in improved system performance.
Measuring the User IT Experience: Traditional system metrics often fail to capture the user IT experience in a meaningful way. Metrics for Individual components of a service can show that the components are healthy even though the user experience less than favorable.
Email Delivery Times: John was motivated to look at ways to measure the user experience when OIT rolled out the expanded email phishing and malware service on June 2016. He wanted to verify that the expanded service which included a more in-depth real-time analysis of URLs and attachments and the rewriting of all email URLs did not have a significant impact on the user experience. He also wanted to determine a baseline for email delivery times.
Working with John, Song Yang, a Master’s student working in ECE, developed several tools last June to measure the end users experience of Duke’s email system. She measured email delivery times from both an on-campus (co-lab) machine and from off campus Amazon Web Services. She tested messages with and without links.
Analysis of the data resulted in the following observations:
- The initial sample data in early June showed that most emails were delivered in less than 1 minute, including emails that contained URLs. However, they found that around 7% of messages were taking an hour or longer. Spikes were traceable to Duke’s on-campus pre-processing of emails that takes place prior to emails being handed off to O365. Spikes were essentially eliminated when the hardware responsible for that process was increased in size. After the hardware changes, messages were taking 15 – 30 seconds to deliver during late night and early morning hours and 45-60 seconds during peak hours. Messages almost never took an hour or more to be delivered.
- URL rewriting does not affect delivery times significantly.
- There was a large decrease in delivery times in October when OIT discontinued an internal email service that served a small portion of Duke’s population. After discontinuing the service, most email messages were being delivered in less than 10 seconds, including messages containing links.
- Microsoft’s processing of emails is always quite fast and became even faster in February.
- Analysis of delivery times for emails containing attachments (ppt and pdf) revealed that messages delivered post Proofpoint attachment scanning were taking at least 5-15 minutes. It also revealed that all messages with attachments (except for very tiny pdfs) were being scanned, not just messages containing macro-enabled attachments as Proofpoint suggested. On February 7th, Proofpoint deployed a software update that excluded non-macro-enabled attachments. After the update, there were major improvements in average delivery times but there were still long-time outliers. Document size seems to be a factor among the outliers.
DNS Resolve Times: Song set up monitoring for DNS (Domain Name Service), the system the internet uses to convert names like duke.edu into addresses. Data included resolution times for a variety of domestic and international addresses, both educational and commercial. The data didn’t reveal anything dramatic that would impact user performance.
Dukeblue Connect Times: Connect times for Dukeblue, Duke’s secure wireless network, were collected the first two weeks in February. Connect time is defined as the time the computer is turned on until there is a working connection to send data. Recent data show that it frequently takes 60 seconds to connect to the Dukeblue network. In addition to Song’s data collection, OIT is collecting data on the time a connection is made until it breaks unexpectedly. It was noted that the changing environment of the wireless network creates difficulties in monitoring the user experience.
What’s Next: John is working with OIT to see if they can operationalize Song’s work since she is graduating.