Getting can not create inner bean error.

[Peter Schober]

* send2amol <amol.choudhari at outlook.com> [2019-09-12 05:26]:
> Now in my SAML-NameID.xml, I have mentioned below beans. But when
> shibboleth returns response to G suite it is returning uid instead
> of email.

That's highly unusual: If the NameIDFormat selection wouldn't work the
IDP will usualy fall back to transient NameIDs.
So whatever the IDP does here you must have configured it to do that.

>     <util:list id="shibboleth.SAML2NameIDGenerators">
>         <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>             p:omitQualifiers="true"
>             p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
>             p:attributeSourceIds="#{ {'mail'} }" />
>     </util:list>

That's not all that affects the NameID format behaviour.
At the very least the subject would have to have an email address
attribute defined in your attribute resolver with an internal id of
'mail'.
And within the attribute filter you'd have to release that 'mail'
attribute to that SP.

You can easily test what NameIDs go out to what SPs using the 'aacli'
command line tool with the '--saml2' parameter, e.g.:

$ /opt/shibboleth-idp/bin/aacli.sh --saml2 -n SOME_USERID -r SOME_SP_ENTITYID

So first you need to find out specifically what NameIDFormat the IDP
sends to the SP. If the format is right but the value is not what you
expected that's something else than the format itself being wrong.

Values for "AttributeSourced"-NameIDs come from attributes defined
within the attribute resolver. They're mapped to NameID formats within
the saml-nameid.xml configurtion.
Finally, NameIDFormat select is based on the SP's metadata or internal
configuration (or individual SAML authentication requests).

All of that is documented in the fine documentation, of course.

-peter