Getting the problem in attribute-resolver.xml

[Peter Schober]

* Surinaidu Majji <pioneer.suri at gmail.com> [2014-12-15 10:05]:
> Based on the suggestions given by many people i started doing changes in
> "attribute-resolver.xml"

Note that those also included posting questions about contributed
extensions (i.e., the code you're trying to use) to the address stated
next to the contribution in the wiki.

> attributes at SP side. I added the following Restful webservice
> Dataconnector and attribute-definition to the attribute-resolver.xml.
> 
> <resolver:AttributeDefinition id="systemSettingData" xsi:type="ad:Simple"
> sourceAttributeID="systemSetting">
>    <resolver:Dependency ref="gws" />
>    <resolver:AttributeEncoder xsi:type="enc:SAML1String"
> name="urn:mace:dir:attribute-def:systemSettingData" />

That attribute name is not assigned by MACE-Dir. You can't just make
up attributes in someone else's namespace.

>    <resolver:AttributeEncoder xsi:type="enc:SAML2String"
> name="urn:oid:2.5.4.43" friendlyName="systemSettingData" />

And the OID 2.5.4.43 also doesn't mean "systemSettingData" (whatever
that should be), it's defined by the ITU-T and ISO to mean "initials"
of an individual's name. Cf. https://tools.ietf.org/html/rfc4519#section-2.14

If you want to define custom attributes you'll need to give them
custom names in a namespace of your own (e.g. a http URL in a DNS
domain you control).

>  <resolver:DataConnector xsi:type="WebService" id="gws"
> xmlns="urn:mace:washington.edu:idp:resolver:dc"
>            authenticationType="NONE"
[...]
>            username="user"
>            password="pass">

Now, which one is it? No authentication to your web service, or some
form of password-based authentication?

>         <QueryTemplate>
>             <![CDATA[
> group_sws/v1/search?member=${requestContext.principalName}&type=effective]]>
>         </QueryTemplate>

That would only work if your web service looked and behaved exactly as
the University of Washington's, of course. In other words, you'll need
to change the QueryTemplate to match your web service's request URL.

> Earlier we used to get principal(attributes) at SP side which have
> been set at the LoginHandler.Principal_Key(AuthenticationEngine).

No. The SP (which is not Shibboleth. so we cannot help with that) does
not access the "principal" which is defined in the IDP. Instead, the
IDP generates a SAML prototol message and sends it to the SP. There is
no "principal" in the SAML, it does not leave the IDP.
What and how you process the SAML on the SP is up to you. If your SAML
SP implementation has the concet of a principal, that has nothing to
do with the principal in the IDP.

Of course Scott aready told you so, so writing this again here is
probably moot.

> After adding the additional above restful dataconector, i am even
> not getting the previous attribute(principal) at SP side. I know my
> restful dataconnector is not the exact one but i could not able to
> figure out what is the reason for not getting the 'principal' also?

Look at your IDP's logs (which are documented in the documentation).
Start with the audit log to determine what data (attributes and
NameIDs) have been sent to the SP.
Then check your process log for any WARN or ERROR lines.
-peter