<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">UA’s integration with Data Cookbook was a while ago. It’s in use here by a relatively small defined group.<div>We release a single attribute in the SAML assertion identifying the user; the vendor had some flexibility to</div><div>use a pre-existing attribute carrying our employee number. We exchanged metadata, but there was no</div><div>custom relying party configuration or unique attribute requirements.</div><div><br></div><div>My vague recollection is that at the time they did not offer JIT provisioning based on attributes - which your</div><div>note indicates is possible now. In any case, we’re not doing JIT provisioning; if a UA User hasn’t been provisioned</div><div>out of band, they are presented with an access request form.</div><div><br></div><div>For UA use, the vendor set up the URL <a href="https://alaska.datacookbook.com/">https://alaska.datacookbook.com/</a> for access. That URL</div><div>issues a GET to the UA IdP </div><pre id="txt"><font face="Monaco" size="1">GET <a href="https://idp.alaska.edu/idp/profile/SAML2/Redirect/SSO">https://idp.alaska.edu/idp/profile/SAML2/Redirect/SSO</a></font></pre><div>with the SAML request:</div><div><br></div><div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px; position: static; z-index: auto;"><?xml version="1.0" encoding="UTF-8”?></div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px; position: static; z-index: auto;"> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol” </div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px; position: static; z-index: auto;"><span class="Apple-tab-span" style="white-space:pre"> </span>AssertionConsumerServiceURL="<a href="https://alaska.datacookbook.com/shibboleth/Shibboleth.sso/SAML2/POST”">https://alaska.datacookbook.com/shibboleth/Shibboleth.sso/SAML2/POST”</a> </div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px; position: static; z-index: auto;"><span class="Apple-tab-span" style="white-space:pre"> </span>Destination="<a href="https://idp.alaska.edu/idp/profile/SAML2/Redirect/SSO”">https://idp.alaska.edu/idp/profile/SAML2/Redirect/SSO”</a> </div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px; position: relative; z-index: 0;"><span class="Apple-tab-span" style="white-space:pre"> </span>ID=“••••" IssueInstant=“••••” </div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px; position: relative; z-index: 0;"><span class="Apple-tab-span" style="white-space:pre"> </span>ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"></div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px;"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><a href="https://alaska.datacookbook.com/shibboleth/shibboleth-sp</saml:Issuer>">https://alaska.datacookbook.com/shibboleth/shibboleth-sp</saml:Issuer></a></div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px;"> <samlp:NameIDPolicy AllowCreate="1"/></div><div style="margin: 0px; font-family: Monaco; background-color: rgb(255, 250, 194); font-size: 10px;"></samlp:AuthnRequest></div></div><div><br></div><div>All in all, one of the less painful non-federated integrations.</div><div><br></div><div>David Bantz</div><div>U Alaska IAM</div><div><br><div><div>On Tue, 23 Sep 2014, at 11:34 , Rob Gorrell <<a href="mailto:rwgorrel@uncg.edu">rwgorrel@uncg.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">anyone familiar or already integrating with the service provider Data Cookbook? Appearently they "<span>provides a central, highly visible location to store all of the
details of your institution’s reporting terminology and report
specifications."</span> <br><br>some quick googling and it looks like our friends at UA have had some experience, so maybe you guys will see this and chime in.<br><span></span><div><br></div><div>I'm looking for some pointers on the setup. Looks as though the vendor has CAS and Shibb experience, and even have a Shibb authentication form collecting:<br>Session Initiator Entity ID</div></div></blockquote><blockquote type="cite"><div dir="ltr"><div>Session Initiator Type<br>Metadata Provider Type<br>Metadata Provider URI<br>User Validation Field (Username or email)<br>options for Auto-Create Users and associated attribute mappings<br>followed by two ubiquitous text blocks of "Configuration Details" and "Additional Details".<br><br></div><div>Could someone offer some translation help about what they are after here? I'm still learning how to parse this stuff our for these generic/direct peerings, but something seems incomplete or abnormal to me about what they are asking. I know my IdP entityID, but are they expecting an unsolicitied/IdP initiated session? No certs means they're not expecting the assertion to be signed or encrypted, right? What are these "Types" and "URI"?<br><br></div><div>Thanks,<br></div><div>-Rob<br></div><div><br></div><div>-- <br><div dir="ltr"><div>Robert W. Gorrell<br>Systems Architect, Identity and Access Management </div>
<div>University of NC at Greensboro<br><span style="white-space:nowrap">336-334-5954</span><br>PGP Key ID B36DB0CA<br></div></div>
</div></div>
-- <br>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a></blockquote></div><br></div></body></html>