[prev in list] [next in list] [prev in thread] [next in thread]
List: shibboleth-users
Subject: Re: Getting the problem in attribute-resolver.xml
From: Surinaidu Majji <pioneer.suri () gmail ! com>
Date: 2014-12-19 7:13:20
Message-ID: CAGNcRLQgFjCODP9qjfSk552xMuY5Q2Sn_N1FX2pBWKRbEaHa3g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@univie.ac.at>
wrote:
>
> * Surinaidu Majji <pioneer.suri@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@shibboleth.net
>
[Attachment #5 (text/html)]
<div dir="ltr">Hello Peter,<div><span style="font-size:12.8000001907349px">Look at \
your IDP's logs (which are documented in the documentation).</span><br \
style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Start \
with the audit log to determine what data (attributes and</span><br \
style="font-size:12.8000001907349px"><span \
style="font-size:12.8000001907349px">NameIDs) have been sent to the SP.</span><br \
style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Then \
check your process log for any WARN or ERROR lines.</span><br></div><div><span \
style="font-size:12.8000001907349px"><br></span></div><div><span \
style="font-size:12.8000001907349px">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. </span></div></div><div class="gmail_extra"><br><div \
class="gmail_quote">On Mon, Dec 15, 2014 at 5:36 PM, Peter Schober <span \
dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" \
target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">* Surinaidu Majji <<a \
href="mailto:pioneer.suri@gmail.com">pioneer.suri@gmail.com</a>> [2014-12-15 \
10:05]:<br> <span class="">> Based on the suggestions given by many people i \
started doing changes in<br> > "attribute-resolver.xml"<br>
<br>
</span>Note that those also included posting questions about contributed<br>
extensions (i.e., the code you're trying to use) to the address stated<br>
next to the contribution in the wiki.<br>
<span class=""><br>
> attributes at SP side. I added the following Restful webservice<br>
> Dataconnector and attribute-definition to the attribute-resolver.xml.<br>
><br>
> <resolver:AttributeDefinition id="systemSettingData" \
xsi:type="ad:Simple"<br> > \
sourceAttributeID="systemSetting"><br> > <resolver:Dependency \
ref="gws" /><br> > <resolver:AttributeEncoder \
xsi:type="enc:SAML1String"<br> > \
name="urn:mace:dir:attribute-def:systemSettingData" /><br> <br>
</span>That attribute name is not assigned by MACE-Dir. You can't just make<br>
up attributes in someone else's namespace.<br>
<span class=""><br>
> <resolver:AttributeEncoder xsi:type="enc:SAML2String"<br>
> name="urn:oid:2.5.4.43" friendlyName="systemSettingData" \
/><br> <br>
</span>And the OID 2.5.4.43 also doesn't mean "systemSettingData" \
(whatever<br> that should be), it's defined by the ITU-T and ISO to mean \
"initials"<br> of an individual's name. Cf. <a \
href="https://tools.ietf.org/html/rfc4519#section-2.14" \
target="_blank">https://tools.ietf.org/html/rfc4519#section-2.14</a><br> <br>
If you want to define custom attributes you'll need to give them<br>
custom names in a namespace of your own (e.g. a http URL in a DNS<br>
domain you control).<br>
<span class=""><br>
> <resolver:DataConnector xsi:type="WebService" \
id="gws"<br> > \
xmlns="urn:mace:washington.edu:idp:resolver:dc"<br> > \
authenticationType="NONE"<br> </span>[...]<br>
> username="user"<br>
> password="pass"><br>
<br>
Now, which one is it? No authentication to your web service, or some<br>
form of password-based authentication?<br>
<span class=""><br>
> <QueryTemplate><br>
> <![CDATA[<br>
> group_sws/v1/search?member=${requestContext.principalName}&type=effective]]><br>
> </QueryTemplate><br>
<br>
</span>That would only work if your web service looked and behaved exactly as<br>
the University of Washington's, of course. In other words, you'll need<br>
to change the QueryTemplate to match your web service's request URL.<br>
<span class=""><br>
> Earlier we used to get principal(attributes) at SP side which have<br>
> been set at the LoginHandler.Principal_Key(AuthenticationEngine).<br>
<br>
</span>No. The SP (which is not Shibboleth. so we cannot help with that) does<br>
not access the "principal" which is defined in the IDP. Instead, the<br>
IDP generates a SAML prototol message and sends it to the SP. There is<br>
no "principal" in the SAML, it does not leave the IDP.<br>
What and how you process the SAML on the SP is up to you. If your SAML<br>
SP implementation has the concet of a principal, that has nothing to<br>
do with the principal in the IDP.<br>
<br>
Of course Scott aready told you so, so writing this again here is<br>
probably moot.<br>
<span class=""><br>
> After adding the additional above restful dataconector, i am even<br>
> not getting the previous attribute(principal) at SP side. I know my<br>
> restful dataconnector is not the exact one but i could not able to<br>
> figure out what is the reason for not getting the 'principal' also?<br>
<br>
</span>Look at your IDP's logs (which are documented in the documentation).<br>
Start with the audit log to determine what data (attributes and<br>
NameIDs) have been sent to the SP.<br>
Then check your process log for any WARN or ERROR lines.<br>
<span class="HOEnZb"><font color="#888888">-peter<br>
--<br>
To unsubscribe from this list send an email to <a \
href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</font></span></blockquote></div></div>
--
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic