Integration with JScape

[Fuhr, Evan C]

Thanks for the input. We definitely don't want to do the worst-case scenario for the same reasons you listed below. We're now engaging the vendor to develop a more compliant SAML endpoint.

Thanks,
Evan Fuhr
Integration Engineer
ITS Applications – Identity and Access Management
The University of Texas at Austin
efuhr at austin.utexas.edu
 

On 6/22/18, 5:30 PM, "users on behalf of Peter Schober" <users-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at> wrote:

    * Fuhr, Evan C <efuhr at austin.utexas.edu> [2018-06-21 21:58]:
    > Has anyone here done a successful integration with
    > JScape<https://www.jscape.com/> and Shibboleth over SAML? We can't
    > seem to pinpoint an entity id or metadata to establish a
    > link. Thoughts?
    
    Their documentation ("WebSSO" at
    http://files.jscape.com/secureftpserver/docs/setting_authentication_prefere.htm#web_sso
    ) doesn't even mention SAML, AFAICT, so you'd have to ask the vendor.
    
    We could help you make guesses, though that's not very efficient and
    may not answer all questions (e.g. "Does the SP support encryption and
    what's the certificate to use?"), but even those questions we can
    probably guess the answer to (forthe above question that would be
    "They don't", usually, unless they sign authn requests.).
    
    Worst-case recipe
    =================
    
    Look at the Authentication configuration when you set "Service type" to
    SAML. If that screen has something like an "SSO URL" in it, try giving
    it the Location from the SingleSignOnService element of your IDP's
    metadata. Try the HTTP-Redirect binding first, if that fails use the
    HTTP-POST location.
    And if it asks for an IDP certificate give it a copy of your IDP's
    signing cert.
    
    Using Mozilla Firefox with the "SAML tracer" extension (or with
    logging in your IDP for the "PROTOCOL_MESSAGE" logger turned up to
    debug) watch out for an authentication request from the SP.  From that
    you can infer the SP's entityID and the ACS URL (and possibly the
    NameID format). Put all those things in a minimal EntityDescriptor and
    load it into your IDP. E.g. something like:
    
    <EntityDescriptor entityID="https://sp.example.og/saml/entity" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
      <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
        <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
          Location="https://sp.example.og/saml/acs" index="1"/>
      </SPSSODescriptor>
    </EntityDescriptor>
    
    Then you'd still have to figure out how they intend to identify a
    subject (e.g. NameID of a certain format, Attributes of a certain
    format and with a certain name; the above example somewhat arbitrarily
    uses email format NameIDs), and if attributes are going to be a part
    of it you'd still have to convince your IDP to send stuff unencrypted.
    
    HTH,
    -peter
    -- 
    For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net