Shibolleth With TribeHR

[Peter Schober]

* Kobi Seviliya <kobi at outbrain.com> [2014-06-06 21:18]:
> We are looking at integrating Shibboleth with TribeHR which supports other
> SAML solutions like OKTA but doesn't officially support shibboleth .
> Therefore they do not give out any metadata file to use with our IDP .

That ("Therefore") is a non sequitur: You don't need to officially
support "Shibboleth" and can still create SAML 2.0 Metadata describing
the essential operational details of your SAML deployment to others in
a standardized (and machine-readable) way.

> 2. can i create a metadata file for them myself ? any guidance on
> that will be much appreciated ...

FWIW, based on a quick web search and
http://irclog.perlgeek.de/openam/2014-04-30/text
a minimal hypothetical Entity Descriptor for their service could look
like this:

  <EntityDescriptor entityID="TribeHR" 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://zw.mytribehr.com/saml/response" index="1"/>
    </SPSSODescriptor>
  </EntityDescriptor>

That assumes the ACS Location URL is the same for all customers
(highly unlikely from experiences with commercial SaaS offerings
relayed here), but you can always look at the authnRequest they send
for you.

Unless you have alraedy done so (e.g for other vendors) you'll have to
create a custom relying party in Shib IDP to disable encryption of
assertions to that RP (otherwise the IPD will b0rk on the missing
certificate), unless you find indication they support that (and the
matching public key).

Assuming they actually cared about the NameID in the assertion's
Subject, you'd need to create an attribute defintion depending
(sourceAttributeID) on your existing email attribute definition, with
I think an attribute encoder of type SAML2StringNameID and
nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
going from memory.  And appropriate filter rules to get that released
(instead of persistentId or transientId).

> Their SAML setup only asks for two fields..  Identity Provider Login
> URL and Identity Provider Certificate

The former is probably your IDP's SingleSignOnService Location
(assuming HTTP-Redirect, otherwise try HTTP-POST)
  https://your.idp.example.org/idp/profile/SAML2/Redirect/SSO
and the latter your IDP's pubic key, allowing them to verify signed
assertions (or responses), seemingly.
HTH,
-peter