Skip to Content.
Sympa Menu

shibboleth-dev - [Shib-Dev] [IdPv3] Profile Handlers

Subject: Shibboleth Developers

List archive

[Shib-Dev] [IdPv3] Profile Handlers


Chronological Thread 
  • From: Chad La Joie <>
  • To:
  • Subject: [Shib-Dev] [IdPv3] Profile Handlers
  • Date: Thu, 22 Jul 2010 08:44:10 -0400
  • Organization: Itumi, LLC

STOP! Before reading the main contents of this email please be sure you have read this:
http://groups.google.com/group/shibboleth-dev/browse_thread/thread/1fcab032218f8ffb

This email deals with the profile handlers, the components configured by means of the <ProfileHandler> elements within the handler.xml file. Note, this does NOT include the per relying party configuration aspects for a profile found in the relying-party.xml file, that aspect will be in another email dealing with configuration.

Following are the things I currently plan to change/add:

- Add support for "conversation". In web applications (and in other areas) conversations are a unit of state for an operation. In particular it deals with the case where an operation and its state last longer than one request/response. This will make the transition from the profile handler to the authentication engine and back again and the from the consent engine and back again much easier to deal with.

- Add the number of current active sessions to the Status handler.

- Incorporate the ECP[1] and Delegation[2] extensions in to the main code base.

- Add support for SAML2 RespondTo extension

- Define and support use of EncryptionMethod within SAML metadata in order to allow an SP to, for example, indicate that it wants AES256 used as opposed to something else.

- Support receiving encrypted NameIDs within protocol messages like attribute queries or SSOS authentication requests.

- Performance metrics for: total time to process request

Following are the things I am currently considering, but not committed to:

- Add support for the SAML 2 Assertion ID request.

- Create a profile handler that generates metadata dynamically by inspecting the currently loaded configuration. I am pretty close to putting this in to the "not to be implemented" pile because of the areas where the IdP would have to guess about what data to fill in. I believe the appropriate way to do this is to continue serving a static file and create a script that can regenerate metadata based on the config and user input.

Following are features I've considered by ruled out for this release:

- Single Logout support.
- ManageNameID support.
- NameIDMapping support.


[1] https://spaces.internet2.edu/display/SHIB2/IdP+ECP+Extension
[2] https://spaces.internet2.edu/display/ShibuPortal/Home

--
Chad La Joie
http://itumi.biz
trusted identities, delivered



Archive powered by MHonArc 2.6.16.

Top of Page