servicenow SAML 2 integration
Christopher Bongaarts
cab at umn.edu
Thu Apr 24 11:07:45 EDT 2014
On 4/23/2014 6:37 PM, Paul B. Henson wrote:
> One of the integration guides I was looking at said it required a custom RelyingParty configuration in relying-party.xml so the idp would not try to encrypt assertions; the example config included encryptAssertions="never".
> [...]
> Evidently they require a NameID format attribute to join to their internal database. Our current configuration only supplies the transientId and eduPersonTargetedID with such an encoding, neither of which is suitable, so it seems a new special attribute must be defined specifically for servicenow that encodes one of our other existing attributes in NameID format? I also read in an older posting that you need to hack the default releaseTransientIdToAnyone policy to explicitly exclude them, is that still true?
Config tip for situations like these:
Collect all your metadata for your various SN instances (you at least
have a test and prod, right?) and surround them with <EntitiesDescriptor
Name="servicenow">. Then you can use the group mechanisms in
relying-party and the attribute-filter to apply their exceptions to all
the instances at once, e.g.
<RelyingParty id="servicenow"
provider="my_idp"
defaultSigningCredentialRef="IdPCredential">
<ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
encryptAssertions="never"
encryptNameIds="never" />
</RelyingParty>
<AttributeFilterPolicy id="servicenowAF">
<PolicyRequirementRule
xsi:type="saml:AttributeRequesterInEntityGroup" groupID="servicenow" />
<AttributeRule attributeID="transientId">
<DenyValueRule xsi:type="basic:ANY" />
</AttributeRule>
<AttributeRule attributeID="principalId">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>
</AttributeFilterPolicy>
--
%% Christopher A. Bongaarts %% cab at umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
More information about the users
mailing list