Non Incommon SPs

Bryan E. Wooten bryan.wooten at utah.edu
Mon Jul 16 20:05:20 EDT 2012


Thank you all for the feedback. I don't know if it confirmation bias or not. But this type a quick response is what makes me a proponent of the open source (especially in Higher Ed) community. I would never expect this response from any of the "big" vendors. I thank you.

I am sure most of us deal with this level of conflict on a daily basis. 

We all know that funding is an issue and I feel it is my responsibility to push back at vendors. This won't be the first or last. For me this is the 3rd HR / recruitment vendor I have had the pleasure of dealing with relating to SSO. Even an Incommon can't do it right. Sigh.

They all fail.

Best Regards.

Bryan 
________________________________________
From: users-bounces at shibboleth.net [users-bounces at shibboleth.net] on behalf of Cantor, Scott [cantor.2 at osu.edu]
Sent: Monday, July 16, 2012 5:18 PM
To: Shib Users
Subject: Re: Non Incommon SPs

On 7/16/12 7:01 PM, "Bryan E. Wooten" <bryan.wooten at utah.edu> wrote:
>
>What are the steps we can make to make this possible? Do we require they
>provide us with their SP's metadata or can we create that on our own. I
>am also not sure about certificate exchange for SAML assertions.

If you care, and if you decide you need to encrypt data to them, then
you'll have to have a way to verify their key. They will not understand
what you mean, or why you care, but that's life. You can save some trouble
by not bothering with a key on their end if you can live with the data in
the clear in the messages.

You may also, based on the eduPerson comment, have to create custom
attribute encodings (or maybe even definitions) in your resolver, which is
a significant change.

>Any idea the level of effort we will need to make this happen (man hours)?

There are too many variables to answer that. It can take me minutes to
several hours or even longer if I'm busy debugging their implementation,
pen-testing it, finding bugs, sitting on phone calls explaining to them
why their code is broken. Not that I've ever done that.

A lot of this comes down to whose data it is. If it's OSU's, then I have
to care or I'm not doing my job. If it's not, then to be honest, they can
do what they like to protect (or botch the protection of) their own data.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list