Shibolleth With TribeHR

[Kobi Seviliya]

Thanks Peter for the Detailed response, will report back if we managed to
pull this off for future reference ...


On Sat, Jun 7, 2014 at 5:29 AM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
 *Kobi Seviliya,* IT Manager

 *T: *073-2238947 *M: *052-6500978 *E: *kobi at outbrain.com

-- 
The above terms reflect a potential business arrangement, are provided solely 
as a basis for further discussion, and are not intended to be and do not 
constitute a legally binding obligation. No legally binding obligations will 
be created, implied, or inferred until an agreement in final form is executed 
in writing by all parties involved.

This email and any attachments hereto may be confidential or privileged. 
 If you received this communication by mistake, please don't forward it to 
anyone else, please erase all copies and attachments, and please let me 
know that it has gone to the wrong person. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140616/6d59b451/attachment.html