Define a relying party profile for AuthnRequestsSigned="true"

Karla Borecky kborecky at smith.edu
Thu Mar 10 16:05:05 EST 2016


Well, I ended up editing their metadata, eliminating the "unspecified"
line, and changing the 'request format email' line to have the urn:oid for
the uid attribute, which is what we're passing.

*<md:NameIDFormat>urn:oid:0.9.2342.19200300.100.1.1</md:NameIDFormat>*
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>


Then I put this in saml-nameid.xml:

     <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oid:0.9.2342.19200300.100.1.1"
            p:attributeSourceIds="#{ {'uid', 'UDC_IDENTIFIER'} }" />

It's definitely generating the NameID using the uid format, but the only
thing I'm not sure about is the UDC_IDENTIFIER name coming across. I mean,
I have it in the attribute-resolver with source attribute of uid, I have it
in their section of the attribute filter - and I see it in the assertion -
but we still get this error when trying to log in:

com.ellucian.sso.exception.ApplicationException: UDC Id not available

The instructions for getting this thing talking to an external IdP aren't
abundantly clear, since they have their own IdP and have just started
supporting talking to someone else's. (In fact, their syntax for how to
return "UDC_IDENTIFIER" with another attribute as a source were just plain
wrong.) So if anyone has got this working - especially knowing what magic
parameters to use in the ssomanager configuration - I would appreciate your
advice.

I'm attaching the assertion produced by aacli as well as a log excerpt, if
anyone has the time or inclination to help.

Thank you!

Karla B

On Thu, Feb 25, 2016 at 1:35 PM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Karla Borecky <kborecky at smith.edu> [2016-02-25 19:31]:
> > Now to tackle their desire to have a NameIDFormat of "unspecified." :-P
>
> I think Scott's current advise here is to first try sending some less
> ill-defined format (with comparabe/compatible values as agreed upon)
> without telling them, to see how specific they are in their
> requirement for "unspecified".
> Certainly makes sense to me, even though it won't always work.
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160310/139583ad/attachment-0001.html>
-------------- next part --------------
./aacli.sh --principal kborecky --requester ssomanager

{
"requester": "ssomanager",
"principal": "kborecky",
"attributes": [


  {
    "name": "uid",
    "values": [
              "StringAttributeValue{value=kborecky}"          ]
  },  

  {
    "name": "fcLogoutUrl",
    "values": [
              "StringAttributeValue{value=https://login.smith.edu/idp/profile/Logout}"          ]
  },  

  {
    "name": "transientId",
    "values": [
              "StringAttributeValue{value=_f3778e31e16258e4764a5a5a4bc3afa4}"          ]
  },  

  {
    "name": "UDC_IDENTIFIER",
    "values": [
              "StringAttributeValue{value=kborecky}"          ]
  }  

]
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssomanager-7March.log
Type: application/octet-stream
Size: 18587 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20160310/139583ad/attachment-0001.obj>


More information about the users mailing list