Getting the problem in attribute-resolver.xml

[Surinaidu Majji]

Hello Peter,
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.

I have checked the logs, I don't have any log statements in the
idp-audit(empty) and there is nothing in the idp-process which is
corresponding to Principal.

On Mon, Dec 15, 2014 at 5:36 PM, Peter Schober <peter.schober at univie.ac.at>
wrote:
>
> * 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20141219/d0f85cd2/attachment.html