Shibboleth Developers

Standard logistics:

Phone #:  800-998-2462
Pin #:  5601277

Agenda items:

1) status - 1.0 release -- see  list of promised features down below
        - known issues?
        - W2K/apache port
        - deploy doc

2) Other issues?


------------- Notes from  last week's call ---------------------

Discussion of status of 1.0 deliverables (see  numbered list at the end)

1. use new error classes on the target side. clean up the error 
messages (wrap them, provide understandable messages). Currently, 
most problems occur during POST (will this continue?). Two causes - 
trust problem, clock skew -- these occur during testing, but probably 
not during production.

robustness -- send two AAs from the HS, have SHAR iterate thru them 
(already in the code) (rpc timing out before it gets to second one, 
tho...)

-- review all the timeout values (eg rpc timeout)

-- config error url into metadata, rather than transferring 
dynamically; expose on  target side with runtime mapper; replace into 
target side template

-- add various error codes to the origin side error url; so origin 
side script could automatically parse (eg clock skew); document what 
we're doing with these codes

2. mysql/target side. mysql uses C++. had to rebuild from source 
(frpm); expected to be straightforward.... but.... took about 12 
hours. mysql not using libtool; using gcc to link...

in the process of ripping apart the old cache file (200 lines of 
code), and writing the mysql plugin. with some luck, this week. but 
certainly within 10+ days.

need to produce a patch to their makefile.. (their = mysql?)

we can probably just include binaries  ofmysql, of what we've built.....

derek keeping all this stuff in a separate package. stored in same 
cvs, but is a different module, under a different name in the cvs.

already someone who wants to do a version for oracle (Buffalo?)...... 
load balance situation... multiple SHARs pointing at same DB separate 
backing store brings up interesting locking issues. Derek needs to a) 
open transaction, b) do his sql, and c) close transaction

3. authmType -- just a few minutes of work; walter will raise flag if 
he doesn't finish; will come from properties file; its required; put 
uri into field; oasis has an UNSPECIFIED value

on target side, define a new ENV variable to hold this value; thus 
need to store somewhere..... derek storing initial authn statement, 
so this is already stored... (needed for bindings) derek would need 
to add an api to the cache code, in order to retrieve the authn 
assertion... shib_rm needs it; extend REQUIRE processing....

4. cert -> metadata -> rewriting dig sig code; no progress last 
week..... (big issue is getting to the apache library) hoping there's 
enuf there for us to build 1.0 on it.....

4. new AA stuff..... well on its way... code checks in, and tests ok 
so far.... but haven't seen much testing. need to contact nate about 
doc.

AI - Urs statement about AAP confusion

what does REQUIRE VALID-USER mean ? response needs at least one one 
attr assertion; zero attr's not acceptable -> not a valid signon; 
sending attr's back but they're filtered on target -> same as zero 
attr's...

5. use local time string values in the target side log files; change 
has already been made

6. Aaron......

AI - stc -- get Aaron on the next call......

AI - changes in structure of deploy guides; documented in some 
emails; from Nate -- breaking into different guides; guide's for 
different sorts of configurations

----------------

2) Status of various questions

	check  status RSA IPR claim on openSAML -- they've released a 
DRAFT of the license application; don't yet have anywhere to fax it 
to..... haven't gotten "the final text" from Rob......

if not ready, put out 1.0 with the same proviso....

AI stc -> Ken...... let I2 lawyers look at text....

-----------------

        robustness -- reloading of sites file

have an independent cron driven process that downloads the file, 
validates sig, and then stores. Apache will then stat the file;link 
against shib-target, read the ini file

provide deployment advice

------------------
find a reasonable home (name space) for these; in mace, but off to 
the side.....

        new attributes
          baseURL -- in an example config file; register uri's
   		  CampusAffiliation -- affiliation -- 
, ; ? prefer to defining a new 
attribute?
   		  Unique persistent opaque ID -- derived attribute; 
no need to store it; NOT reversible; needs description/ definition; 
unique to the SHAR and the user; define at the attribute level, or 
the federation? SHA1 hash. persistent_handle

   		  profile X500 attributes -- use XACML convention for 
referencing attributes  (in a HTTP url); code may have hard-coded the 
mace namespace....; walter is hard-coded to send that ......

          recommendations, thoughts on COURSE, DEPARTMENT

AI - in eduperson examples, change from 1.0...... come up with scheme 
for urn's....

COURSE -- target/vendor has to provide functionality that maps 
entitlement value to local course code; too much variation from 
campus to campus in how they encode course names....

DEPARTMENT -- bury in afifliation? assert entitlement. need 
scenario's in the law or business school...... do scenario's include 
complex conjunction of values?

---------------------------------

Standard logistics:

Phone #:  800-998-2462
Pin #:  5601277

Bob's in Amsterdam, and presumably will miss the call....

Agenda items:

1) status - 1.0 release -- see  list of promised features down below
        - known issues?

2) Status of various questions

        check  status RSA IPR claim on openSAML
        mace urn  value "looking likely"...?

3) Other issues?

        exporting SamlAuthnType -- how would an app get this value?
        Aaron - status, cvs......
        robustness -- reloading of sites file
        new attributes
                 baseURL
                  CampusAffiliation
                  Unique persistent opaque ID
                  profile X500 attributes
                 recommendations, thoughts on COURSE, DEPARTMENT

------------- current list  of promised 1.0 features ---------------------

Here's the current  list -- please note that, as with any software 
development process, last minute changes may occur.......

1) Various improvements to error handling. The most noticeable will 
be that origin sites, when they join a federation, will be able to 
supply the url for a local "shib problem resolution" page; this url 
will be distributed in metadata to targets. When a target encounters 
an error, it will be able to substitute this url into an error 
template (replacing a new variable -- origin_error_url).

2) Improved target side robustness. There will be a new SHAR option, 
allowing the SHAR to store its session and attribute cache in 
permanent backing store (in addition to the current in-memory option).

3) OpenSAML will populate the AuthnType element in the SAML Subject 
element. Origin sites will supply the value with a configuration 
directive. The Type value will describe the type of authentication 
mechanism used at the origin site (eg kerberos,  PKI, etc).

4) OpenSAML - origin sites whose HS cert is NOT signed by one of the 
trusted roots will be able to provide InCommon with the HS' cert; 
targets will be able to use this cert to validate the HS' signature.

4) Extend the Attribute Authority implementation, providing backend 
attribute plugins. This should greatly simplify the process of 
extending the AA to support additional attributes.

5) Target side -- can we do this? -- use local time string values in 
the target side log files.

6) (possibly) support for using W2K and  Apache as a target

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--