Issues getting PagerDuty which uses SAML 2.0 to talk to Shibboleth IDP.
Cahill, Charles (GE Appliances)
Charles.Cahill at ge.com
Mon Jun 1 14:18:31 EDT 2015
I am trying your response below as well.
Trying to add in the relying party info to the <DefaultRelyingParty>. Like this.
<rp:DefaultRelyingParty id="https://ge-appliances.pagerduty.com"
provider="fssfedidpdev.al.ge.com"
defaultSigningCredentialRef="IdPCredential"
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
<!--
Each attribute in these profiles configuration is set to its default value,
that is, the values that would be in effect if those attributes were not present.
We list them here so that people are aware of them (since they seem reluctant to
read the documentation).
-->
<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true"
assertionLifetime="PT5M" assertionProxyCount="0"
signResponses="never" signAssertions="always"
encryptAssertions="never" encryptNameIds="never"
includeConditionsNotBefore="true"/>
<rp:ProfileConfiguration xsi:type="saml:SAML2LogoutRequestProfile"
signResponses="conditional"/>
</rp:DefaultRelyingParty>
Also, metadata looks like this:
<EntityDescriptor entityID="ge-appliances.pagerduty.com">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://ge-appliances.pagerduty.com/sso/saml/consume" index="0"/>
</SPSSODescriptor>
</EntityDescriptor>
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of IAM David Bantz
Sent: Monday, June 01, 2015 1:52 PM
To: Shib Users
Subject: Re: Issues getting PagerDuty which uses SAML 2.0 to talk to Shibboleth IDP.
On Mon, Jun 1, 2015 at 9:05 AM, Cahill, Charles (GE Appliances) <Charles.Cahill at ge.com<mailto:Charles.Cahill at ge.com>> wrote:
Okay, am I supposed to generate some fake metadata to put in on the shib IDP side since I cannot get any out
of PagerDuty?
I believe so, yes. If they don't provide a certificate, you may also need to include a custom relying-party config for them.
<!-- VendorX provides no metadata or cert, so fake it -->
<EntityDescriptor entityID="https://X<https://urldefense.proofpoint.com/v2/url?u=https-3A__X&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=Ay4xjbXoe6YvlvYwTANr9ZsOm6cEXvasE-gwLIuoyN8&m=Jzs70RUvY8u6NbB-nPEdjntUuEb43WnZe5-aFa0-7Yc&s=83RwAY7c3LWEtmbpGLEMiH2jdW6YsS-5vbiWkyshFOo&e=>.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:Extensions xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<mdui:UIInfo xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui">
<mdui:DisplayName xml:lang="en">Vendor X Service</mdui:DisplayName>
</mdui:UIInfo>
</md:Extensions>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="{They will have to give you this much - a URL}" />
</SPSSODescriptor>
</EntityDescriptor>
in relying-party.xml (Shibb 2):
<!-- VendorX provides no metadata or cert, so disable encryption -->
<RelyingParty id="https://X.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__X.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=Ay4xjbXoe6YvlvYwTANr9ZsOm6cEXvasE-gwLIuoyN8&m=Jzs70RUvY8u6NbB-nPEdjntUuEb43WnZe5-aFa0-7Yc&s=-WLgJqrWVThMn0PgZQsRqS8Roh-n2OLrMC4Z2cHT_H4&e=>"
provider={yourEntityID}
defaultSigningCredentialRef="IdPCredential"
defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"> <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
</RelyingParty>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150601/037b14f5/attachment-0001.html>
More information about the users
mailing list