Additional information from the IDP login screen?

[Peter Schober]

* cdd mb1 <cddmb1 at gmail.com> [2014-10-16 18:05]:
> I'm relatively new to shibboleth (and SAML), and I have what I hope is a
> simple question: Is there any way to propagate additional user-entered
> information from the idp login screen to an SP?  Say the login screen has 3
> fields: username, password, and org where org is user-entered. Is there any
> way to include the entered value for org as an attribute inthe assertion to
> the SP?

Several things to note:

The IDP does not usually grab data from the login screen and sends it
off to SPs "directly".  The IDP /can/ grab data from different places
(among them the entered username and even the entered password, in
certain deployments) but grabbing and encoding and releasing it as a
SAML attribute are seperate steps, not something that flows from the
login form to SPs "naturally".
(Of course SPs never get the password entered at the IDP and more
often than not they also don't get the string entered as username, but
some other identifier better suited to the IDPs and/or SP's
requirements.)

Also note that if the subject can chose which org (unit) s/he belongs
to that this is not really trustworthy information. Much better to
look up that info from an authoritative data source, based on the
authenticated principal.
Besides issues of data provenance (subject vs. data source) letting
people enter their org (unit) as free form strings is likely to lead
to inconsistent data at the SP, due to different ways to spell
something, human error, etc. (A dropdown list would void those, though.)

So basically you'd only ask for the minumum data you need to uniquely
identify a subject (login name, or kerberos principal or email address
or whatever; credentials to verify) and look up and release any other
additional information based on trusted data systems.

Finally, even if what you wanted can be made to work, this would only
be the case for the first SP anyone accesses, all further requests
will not generate the login page due to SSO.  Unless you disable SSO
and force people to fill out the login form each and every time.

So plenty of reasons not to do that, IMHO.
-peter