2013-03-29

Owned by Tom Zeller
Last updated: Mar 31, 2013 by Scott CantorVersion comment
4 min read

Shibboleth Developer's Meeting, March 29, 2013

Attendees: Tom, Scott, Rod, Ian, Brent, Daniel, Marvin

Call Administrivia

Next call is next Friday.

Suggest a 60 to 90 minute call window, so 10 to 15 minutes per person.

Ian (via list) suggested sticking to 60 if possible to encourage brevity.

Brent

AI: Security advisory for HTTP client issue in V2.

Closed most of the misc bugs open. One more to review, may be nothing to do, will verify.

Scott: thinking maybe end of next week or beginning of next for release.

Daniel

Work : Spring wiring for LDAP data connector

Potential configuration options for LDAP configuration:

<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
   ldapURL="ldap://localhost:10389" 
   baseDN="ou=people,dc=shibboleth,dc=net" 
   principal="cn=Directory Manager"
   principalCredential="password">
   <dc:FilterTemplate>
     <![CDATA[
       (uid=$requestContext.principalName)
     ]]>
   </dc:FilterTemplate>
 </resolver:DataConnector>


<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory">
  <beans>
    <bean id="connectionConfig"
          class="org.ldaptive.ConnectionConfig"
          p:ldapUrl="ldap://localhost:10389">
      <property name="connectionInitializer">
        <bean id="bindConnectionInitializer"
              class="org.ldaptive.BindConnectionInitializer"
              p:bindDn="cn=Directory Manager"
              p:bindCredential="password"/>
      </property>
    </bean>
    <bean id="searchExecutor"
          class="org.ldaptive.SearchExecutor"
          p:baseDn="ou=people,dc=shibboleth,dc=net"/>
  </beans>
</resolver:DataConnector>

Scott/Rod were happy with the proposal. Tom withdrew objection from Columbus about recursively supporting the Spring config schema after Daniel developed a way to handle it without much effort. Issues with supporting this in the schemas were discussed. Probably will be necessary to support this across all data connectors at least, but this shouldn't be a big deal.

Ian

Work: Pending XmlSecTool 1.2.0 release.

Nothing to report.

Rod

Work : Attribute Scripting Environment

  • Scripting API adjusted as discussed in development mail list.  
  • Preliminary documentation written, then updated appropriately.  As usual, this took longer than anticipated.  
  • Legacy classes written, testing ongoing.  Checkin by Apr-1,
  • Still some issues with cobatura, but aiming to get code coverage and thus enhance testing

Next week: Look at Attribute Resolver configuration parsing.
 

Scott

AI : Further thoughts on setting up an Active Directory VM for integration/unit tests ?

Work : Pending IdP 2.4.0 release.

  • Another round of dependency updates, mostly logging, think I'm done.
  •  Issue: Remove scripting engines? Wait for 3.0? Will circulate to list.
  • Mike G finishing up login page changes and helping with some testing.
  • Release dry run next week.

Work : AACLI

  • Command line shell with jcommander, Spring loaded logging, Velocity, ParserPool, Webflow container
  • Issue: OpenSAML init / parser injection?
  • Remove dependence on Xerces/Xalan? Security manager changes based on parser used.

Working on refactorization of Actions:

  • Copied ProfileRequestContext into opensaml-messaging-api
  • Created EventContext, new type of context subclass to use as "output" of Profile Actions designed for flow action use
  • Created ProfileAction and AbstractProfileAction to operate on ProfileRequestContext (a la MessageHandler operating on MesageContext)
  • Suggest we create SpringContext to carry Spring/Webflow-specific objects, HttpServletContext to carry Servlet request/response, switch to context-based input/output contracts between components 
  • Will create a ProfileActionWebflowAdaptor (or some such) that wraps a ProfileAction, populates Spring/HttpServletContexts, executes action, checks for EventContext and wraps/returns Event

Some general questions raised about implications of this refactoring:

  • Context tree meant to be stored in Spring context. Scott: not a problem, the adaptor class would take care of that.
  • Using context tree to carry access to servlet objects requires that the context be refreshed with the right request/response objects each time into the server. Scott: yes, the adaptor would need to handle that also.
  • Marvin noted this might complicate the webflow config. Scott agreed, doesn't think we should do anything to complicate that, so that would be a problem.
  • Tom: sounds good, but not sure yet how this will look, will await check-in.
  • Scott will try and get something checked in early next week.
Tom

AI : Email list regarding Active Directory test instance ? Prefer our own.

AI : Figure out establishing a handful of alpha testers ?

AI : Read https://github.com/serac/shibboleth-idp-ext-cas, compare to https://github.com/tomzeller/java-identity-provider-app

AI : Documentation for getting started with writing actions for profile handlers ?

Work : Attribute Filter design and spring wiring.

TODO : Clean up Spring wiring pattern in idp-attribute-resolver-spring and idp-core.

TODO : Fix broken Jenkins project hierarchies. INFRA-75

TODO : Figure out how to purge local maven repository when building some jobs in Jenkins. 

Jenkins now displays links to Javadoc for the java-identity-provider and java-opensaml projects. INFRA-76

To what extent can we modify schemas ? Suggested to Daniel that we can add to a schema as long as we preserve backwards compatibility. Is this correct ?

Scott: yes, in general, unless wildcard elements (<any>) are used. Can review any proposed changes for impact.

Should -api modules have .api in package name? No opinions expressed for or against.

Should we refactor "filtering" to "filter" ? Would result in an AttributeFilterEngine in the net.shibboleth.idp.attribute.filter[.api] package in the idp-attribute-filter-api module. Right now it is a little inconsistent. No objections to this were raised.

Decisions

Coding convention : getLdapUrl or getLDAPURL

With Brent favoring getLdapUrl and Scott seeming to agree for predictability, do we have consensus on getLdapUrl ?

Brent actually isn't strongly in favor, kind of prefers the approach of using all caps unless two acronyms in a row. Scott doesn't like the inconsistency of different rules for different cases.

Daniel suggested looking at the Java coding standards from Sun, but they don't actually address the issue, nor are Java APIs consistent on it.

Tabled for further discussion.