integration with Data Cookbook

[David Bantz]

UA’s integration with Data Cookbook was a while ago.  It’s in use here by a relatively small defined group.
We release a single attribute in the SAML assertion identifying the user; the vendor had some flexibility to
use a pre-existing attribute carrying our employee number.  We exchanged metadata, but there was no
custom relying party configuration or unique attribute requirements.

My vague recollection is that at the time they did not offer JIT provisioning based on attributes - which your
note indicates is possible now.  In any case, we’re not doing JIT provisioning; if a UA User hasn’t been provisioned
out of band, they are presented with an access request form.

For UA use, the vendor set up the URL https://alaska.datacookbook.com/ for access.  That URL
issues a GET to the UA IdP 
GET https://idp.alaska.edu/idp/profile/SAML2/Redirect/SSO
with the SAML request:

<?xml version="1.0" encoding="UTF-8”?>
   <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol” 
	AssertionConsumerServiceURL="https://alaska.datacookbook.com/shibboleth/Shibboleth.sso/SAML2/POST” 
	Destination="https://idp.alaska.edu/idp/profile/SAML2/Redirect/SSO” 
	ID=“••••" IssueInstant=“••••” 
	ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
   <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://alaska.datacookbook.com/shibboleth/shibboleth-sp</saml:Issuer>
   <samlp:NameIDPolicy AllowCreate="1"/>
</samlp:AuthnRequest>

All in all, one of the less painful non-federated integrations.

David Bantz
U Alaska IAM

On Tue, 23 Sep 2014, at 11:34 , Rob Gorrell <rwgorrel at uncg.edu> wrote:

> anyone familiar or already integrating with the service provider Data Cookbook? Appearently they "provides a central, highly visible location to store all of the details of your institution’s reporting terminology and report specifications." 
> 
> 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.
> 
> 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:
> Session Initiator Entity ID
> Session Initiator Type
> Metadata Provider Type
> Metadata Provider URI
> User Validation Field (Username or email)
> options for Auto-Create Users and associated attribute mappings
> followed by two ubiquitous text blocks of "Configuration Details" and "Additional Details".
> 
> 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"?
> 
> Thanks,
> -Rob
> 
> -- 
> Robert W. Gorrell
> Systems Architect, Identity and Access Management
> University of NC at Greensboro
> 336-334-5954
> PGP Key ID B36DB0CA
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140923/8b140953/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://shibboleth.net/pipermail/users/attachments/20140923/8b140953/attachment.bin