Scribing Template --Wed., Nov 13, 2013 at 9am -- Santa Clara Room

TOPIC: Web login UI engines

CONVENER: Nathan Dors

SCRIBE: Jim Fox

# of ATTENDEES:  8

MAIN ISSUES DISCUSSED:

UW situation:  Existing weblogin UI supports pubcookie directly; supports Shib by front-ending the Idp.
Could support others.  What will be the the best way in the future to allow a single UI to support multiple protocols?
It is difficult to propagate specific auth requirements through a protocol handler, elg. Shib IdP,  and onto the UI handler, e.g. UW's weblogin.  It is much more convenient to have the core UI support as many apis as possible by itself.  
Scott C. noted that the v3 IdP will be able to support CAS and OpenidConnect, although maybe not right out of the box.
And that other protocols might be supported with custom code provided by contributors.
Customizations of the shib UI are much easier than v2.
Idp v3 has more easily implemented business rules.  Requested SP Authn class gets translated to custom principal list in idp.  The authn engine dispatches the request to whichever engines can provide the proper login.
Jim:  Possibly we could provide a pubcookie hander.  Had never considerer that before.
Shib is traditionally quite a 'heavy' login, requiring resolution of all attributes on all logins. 
Scott reported that in v3 it will be much easier to resolve only those attributes that are needed.
Permanent storage for uapprove data or session data is by a storage API and will be 'easily' extensible.

UW situation:  Existing weblogin UI supports pubcookie directly; supports Shib by front-ending the Idp.

Could support others.  What will be the the best way in the future to allow a single UI to support multiple protocols?

It is difficult to propagate specific auth requirements through a protocol handler, elg. Shib IdP,  and onto the UI handler, e.g. UW's weblogin.  It is much more convenient to have the core UI support as many apis as possible by itself.  

Scott C. noted that the v3 IdP will be able to support CAS and OpenidConnect, although maybe not right out of the box.

And that other protocols might be supported with custom code provided by contributors.

Customizations of the shib UI are much easier than v2.

Idp v3 has more easily implemented business rules.  Requested SP Authn class gets translated to custom principal list in idp.  The authn engine dispatches the request to whichever engines can provide the proper login.

Jim:  (not thinking this through) Possibly we could provide a pubcookie hander.  Had never considerer that before.

Shib is traditionally quite a 'heavy' login, requiring resolution of all attributes on all logins. 

Scott reported that in v3 it will be much easier to resolve only those attributes that are needed.

Permanent storage for uapprove data or session data is by a storage API and will be 'easily' extensible.

ACTIVITIES GOING FORWARD / NEXT STEPS:

Shib v3 due out fall, 2014, the authn section is available for plugin development now.

If slides are used in the session, please ask presenters to convert their slides to PDF and email them to acamp-info@incommon.org