Attendees
Matt, Chris, Joe, Michael from Unicon
Jimmy
Tim
Nate
Agenda and discussion
1. Pilot Ecosystem Updates
a. IdP and LDAP – Nate & Unicon
LDAP: Most effort has been under the surface. First few weeks was getting somethiing up to get numbers, now backfilling to get to production requirements. Infrastructure required to get this running and sustainable. Fixed init script for Jetty (writing a new one). A bunch of effort on Salt. Was running commands manually, switched over to persistant state that maintains itself. It's aware of it's own architecture and constantly tries to maintain it's architecture. Whether or not that's desirable in full production is a matter for discussion, but good for pilot.
We are due to wrap up config and testing of LDAP by next Wednesday. Will we make that? "Interesting question." Need to look at LDAP replication over the next few days. Nate looking into SSL communications. We may need to bug MRG about that, but it looks straightforward in 389. We'll know when we know. Goal was to hit 600 logins per second next week, even if it takes being over provisioned. THen transition into availability work. Might be a few days behind.
On the IdP side, another configuration finished, now 85 - 90% done. Need to align attributes sending and receiving with LDAP and CPR, but that won't be a lot of work.
Agenda items for F2F at PESC? Nothing off-hand. Agenda for next call: Turn on SSL for all comms, having LDAP replication in place, having LDAP achieving milestones. Hope for 600 logins per second before PESC. Nate will be at PESC and have plenty of stuff to show at meeting.
General information on Silver coming to help resolve earlier tech questions regarding load balancing. Silver probably won't be achievable on Amazon's load balancer, because it appears that we can't keep silver if we run through a 3rd party device.
b. CPR – Jimmy
Configured 2nd VM. PostGRES streaming replication running. Active MQ failover is set up. Persistance with message queuing set up. Everything needed for 2nd box is there. Everything up on the VMs. No load testing done yet. He will need a load balancer at some point. Just finished before lunch, so no load testing done yet. Nate will set up load balancer for Jimmy "pretty quickly." Traffic will be encrypted.
We are using self-signed certificates for everything until we get real domain names.
2. User Experience
a. Open Questions from Unicon
i. For the Pilot, can we narrow the scope to latest versions of the following browsers (i.e., Chrome, Firefox, Safari)
No. We are trying to get as broad of an audience as possible.
ii. Does the design need to be pixel perfect across all browser implementations?
Not as long as it works. Trying now to define the minimum set of browsers we want tested. Hit major browsers, current - ?. Internet Explorer 10 - 9, with emphasis on 9 and 10. Safari and Chrome both use the same html rendering library. So, Safari 6 - 5. Most recent versions of Firefox (20) and Chrome.
iii. Error Handling: The original screen mockups depict unique error handling that highlights an incorrect form field with a hovering red arrow indictor.
Unicon has suggested that given our tight deadline, that we place this custom error handling functionally temporarily out of scope.
To save time, we can instead fall back on the error handling that ships with both Shibboleth and CPR applications.
We can certainly put time and effort into making these visually appear to be the same. If time permits, we can then circle back to the orignal design and estimate out the effort to implement his approach.
Thinking forward on the application. They can develop a skin that's responsive to different screen sizes. On large screens we have an error that indicates that "this field is an error." That looks great on large desktops, but not so much on tablets and smaller devices. Inline handling is better. Box becomes red and an error on the top of the form. Recommends that for the initial pilot we use inline error handling and if time permits implement a fancier solution later.
b. Open Questions from Functional Design Document
i. Registration Screens: Do we need to collect a telephone number type on the Additional Information screen?
ii. Registration Screens: Do we want to collect multiply telephone numbers?
One number, default to "Permanent."
iii. Password Reset Screen: Upon successfully resetting password, where does the user get returned to? The Login Screen?
Return to identity provider context. Ideally the password reset mechanism understands where the user came from and the IdP will understand the context. It looks like we can redirect back to the login page. CPR has that functionality. After a new registration takes place, they get their confirmation page that they can edit. They successfully register, then they get a status code and redirect to login page at the identity provider, where they get a happy message. They log in, then are returned to the referring SP. For password reset, when successful, user redirected to the login screen with a different status code.
iv. Password Reset Screen: If any of the security questions are NOT answered correctly, what happens? Ask 3 questions, require all correct at least through usability testing, then possibly circle back to make other changes.
c. Discussion on possible accelerated delivery date for the UI Screens
Matt feels confident that they can get things to us the week of May 20th. We need the UMBC demo SP back up and configured.
3. Next Week
No calls scheduled. 1/2 tech team at PESC data summit. Tim will arrange teleconference bridge for the last part of that session
4. Next Call
May 9 for tech team and user experience. Nate will approach UMBC about getting their SP environment set back up and modified. Paul Riddle.