OpenSAML dependency on Velocity breaks application

[Tom van den Berge]

On Wed, May 2, 2012 at 2:57 PM, Chad La Joie <lajoie at itumi.biz> wrote:

> On Wed, May 2, 2012 at 8:28 AM, Tom van den Berge
> <tom.vandenberge at gmail.com> wrote:
> > I'm not sure what you mean with an "open" IdP, but if that means that one
> > would have to register with shibboleth.net, and it is branded as such,
> that
> > would be fine. I haven't seen a Jira installation not doing it like
> this, so
> > that is what surprised me on your site.
>
> Sorry, by "open" I meant that anyone would be able to create an
> account (i.e., not just people in a particular organization).
>
> Right, you don't see this much because Atlassian goes out of their way
> to make sure their products can't be integrated with external
> authentication systems.  The cynic in me notes that they sell a
> separate product to sorta does this and so have a financial incentive
> to ensure such integration is difficult in any of their other systems.
>
> > What would you do if you wanted to raise an issue on my Jira, and I would
> > let you set up an account with a seemingly unrelated company that you
> don't
> > know?
>
> Well, relationship clearly isn't the issue here.  You said you would
> be fine using a Google account and there is no relationship between
> them and your Jira.  The crux of the issue is really whether you trust
> any given organization with some subset of your data.


Spot on!


> I happen to be
> okay with Google having a limited subset of my data so I'd be okay
> using them for something like this.  If some one said I had to use
> Facebook I'd tell them to go to hell because I don't trust that
> organization at all.
>
> So, to answer your specific question.  If your directions listed the
> people your Jira instance accepted then I'd look for one that wasn't
> on my blacklist of organizations (e.g., Facebook) and that didn't ask
> for an unacceptable amount of data[1] and I'd use them.  If there was
> no IdP left after my little mental filtering process then I wouldn't
> create an account.
>

Then the difference with my approach is that I only allow IdP's that are on
my whitelist, while the approach you're describing is: allow if not on your
blacklist. That's why I don't use ProtectNetwork, while apparently you
would trust an IdP you don't know.


>
> So, I understand your mental filtering process might exclude
> ProtectNetwork.  And from what you said, a seemingly related domain
> name and site appearance would be enough to allow a given IdP to make
> it through that filtering process.  Which is good info for us.
>

If I'm registering with your domain, while you technically have outsourced
it to some other party, without me knowing this, I would think and expect
my data is kept in your company's domain, and not have a problem with it.
But if I would find out that you send my data to another company, I
wouldn't be very happy ;)

>
> While we're discussing this then, would it have mattered at all if
> ProtectNetwork (or any other randomly selected IdP) had displayed our
> logo, service name, and description on their page and stated you were
> jumping through these hoops in order to work with our app?
>

That would help. You would have to clearly explain why you have outsourced
your identity management to another party. What is ProtectNetwork going to
do with my data? What is their business model; how do they make money? In
other words, why should I trust this company with my data? Only then I can
decide if I add this company to my whitelist.

Still, not having to sign up, but authenticate through e.g. Google would be
preferred though.

Thanks for the good discussion,
Tom

>
>
> [1] Incidentally, I think many people have a totally irrational view
> of what is an acceptable set of data to provide to account bearing
> organizations.  Anyone who thinks, for example, that asking for their
> name, physical address, phone/fax/mobile number, or email address is
> too much data doesn't understand that all that data is public data,
> either by law (in the US) or in effect.
>
> --
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20120502/cd5d6944/attachment.html