Shibboleth Developers

["Dharam Veer" <>]

Thanks Christopher.

I did the same except for storing the attributes in database and using JDBC DataConnector. What I did was that I stored the attributes in the Subject as one principal. Since Subject is available through UserSession (which I could obtain from resolution context) in my custom data connector. 

I think that doing this way eliminate the case for some custom cleanup job as it would be cleaned up as part of sibboleth built in session expiry functionality.

Please do mention if you see something wrong in this approach. 

[No I do not need to store a persistent copy for the moment]

Regards

On Mon, Oct 27, 2008 at 9:29 AM, Christopher A Bongaarts <> wrote:

In the immortal words of Dharam Veer:

> In brief, I want user to submit the attributes using a web form at the time
> of authentication. Doing this help me obtaining the user's consent as well.

If you want to let them submit the attributes at authentication time
(not attribute query/post time), you should probably have your custom
login handler take care of the redirection to the form, and let the
form populate a backend database to store the attributes (short term)
associated with the particular login session.  If you're using
transient nameIDs, you could tie it to that since they are unique to a
session.  Then you can just use the existing database (JDBC?)
DataConnectors to pick up the attributes.  You'd probably also need to
build some sort of cleanup/garbage collection job to periodically
purge old sessions from the DB.  Or, if you expect the users to come
back again later, you could also store a persistent copy tied to a
username or other persistent ID (and use it to prefill the per-login
attribute form each time to minimize typing).

%%  Christopher A. Bongaarts  %%         %%
%%  Internet Services         %%  http://umn.edu/~cab  %%
%%  University of Minnesota   %%  +1 (612) 625-1809    %%