publish new plugin permission

[Bradley Beddoes-2]

Hello,

Per the instructions at http://grails.org/Creating+Plugins I would like permission to publish a new plugin please.

grails.org username: bbeddoes

name of plugin: federated-grails

source url: https://github.com/ausaccessfed/federatedgrails

If you require any further details please let me know.

thanks,

Bradley

[Graeme Rocher-4]

Approved

On Fri, Jun 22, 2012 at 5:28 AM, Bradley Beddoes
<[hidden email]> wrote:

> Hello,
> Per the instructions at http://grails.org/Creating+Plugins I would like
> permission to publish a new plugin please.
>
> grails.org username: bbeddoes
> name of plugin: federated-grails
> source url: https://github.com/ausaccessfed/federatedgrails
>
> If you require any further details please let me know.
>
> thanks,
> Bradley

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[pledbrook]

Hi Bradley,

> Per the instructions at http://grails.org/Creating+Plugins I would like
> permission to publish a new plugin please.
>
> grails.org username: bbeddoes
> name of plugin: federated-grails
> source url: https://github.com/ausaccessfed/federatedgrails

Thanks for the contribution. I've added some comments to the code on
GitHub, but I wanted to bring up one of them here so we can discuss
it.

As I mentioned in the comments, I would prefer to include Shibboleth
in the name of the plugin. Alternatively, how about
'federated-authentication' or simply 'federated-auth'? I certainly
think 'grails' doesn't need to be in the name.

Thoughts?

Thanks,

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Bradley Beddoes-2]

Hi,
I've made the few minor changes requested in your comments.

However not the name. The folks paying for the development chose that and it is part of a larger package of cross technology plugins using similar naming:
* federated-grails
* federated-rails
...
* federated-xyz

So it makes sense from their point of view. It is also integrated into several into Grails apps now so changing it there would also take time I don't really have currently.

Of course if this is going to be sticking point for the Grails team side we could return it to being a source only plugin?.

cheers,
Bradley

On 22/06/2012, at 7:28 PM, Peter Ledbrook wrote:

> Hi Bradley,
>
>> Per the instructions at http://grails.org/Creating+Plugins I would like
>> permission to publish a new plugin please.
>>
>> grails.org username: bbeddoes
>> name of plugin: federated-grails
>> source url: https://github.com/ausaccessfed/federatedgrails
>
> Thanks for the contribution. I've added some comments to the code on
> GitHub, but I wanted to bring up one of them here so we can discuss
> it.
>
> As I mentioned in the comments, I would prefer to include Shibboleth
> in the name of the plugin. Alternatively, how about
> 'federated-authentication' or simply 'federated-auth'? I certainly
> think 'grails' doesn't need to be in the name.
>
> Thoughts?
>
> Thanks,
>
> Peter
>
> --
> Peter Ledbrook
> Grails Advocate
> SpringSource - A Division of VMware
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-4]

No problem, keep the name

Cheers

On Mon, Jun 25, 2012 at 1:11 AM, Bradley Beddoes
<[hidden email]> wrote:

> Hi,
> I've made the few minor changes requested in your comments.
>
> However not the name. The folks paying for the development chose that and it is part of a larger package of cross technology plugins using similar naming:
> * federated-grails
> * federated-rails
> ...
> * federated-xyz
>
> So it makes sense from their point of view. It is also integrated into several into Grails apps now so changing it there would also take time I don't really have currently.
>
> Of course if this is going to be sticking point for the Grails team side we could return it to being a source only plugin?.
>
> cheers,
> Bradley
>
> On 22/06/2012, at 7:28 PM, Peter Ledbrook wrote:
>
>> Hi Bradley,
>>
>>> Per the instructions at http://grails.org/Creating+Plugins I would like
>>> permission to publish a new plugin please.
>>>
>>> grails.org username: bbeddoes
>>> name of plugin: federated-grails
>>> source url: https://github.com/ausaccessfed/federatedgrails
>>
>> Thanks for the contribution. I've added some comments to the code on
>> GitHub, but I wanted to bring up one of them here so we can discuss
>> it.
>>
>> As I mentioned in the comments, I would prefer to include Shibboleth
>> in the name of the plugin. Alternatively, how about
>> 'federated-authentication' or simply 'federated-auth'? I certainly
>> think 'grails' doesn't need to be in the name.
>>
>> Thoughts?
>>
>> Thanks,
>>
>> Peter
>>
>> --
>> Peter Ledbrook
>> Grails Advocate
>> SpringSource - A Division of VMware
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[aaronzirbes]

Hi Bradley,

It's good to see someone integrating Shibboleth into another Grails security framework!

As the author of the spring-security-shibboleth-native-sp plugin, I hope you'll take a suggestion.

1st is a heads up that Shibboleth isn't the only federated sign-on system and it looks like your plugin only ties in to shibboleth.

2nd, Your plugin doesn't directly implement the SAML2 protocol, and requires the Apache mod_shibXX libraries, which are referred to as the "Shibboleth Native SP".  Not all frameworks require this (mine does, just like yours), so it'd be nice to see this referred to as the "Shibboleth Native SP", as "Shibboleth SP" can refer to anything implementing itself as a service provider.  A link to the "Shibboleth Native SP" would also help folks get what they need rather than just referring to it by name.  Here's my link:  https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfiguration

As a side note, I also would have liked to see "shibboleth" in the plugin title.  "shiro" in the title would have been nice as well.   Also using the word 'grails' in a Grails plugin is a bit redundant.  I know it's probably too late.

I know you mentioned Rails, so if it helps, there is already a Rails plugin for Shibboleth that's really nice. (https://github.com/jgeorge300/devise_shibboleth_authenticatable).  Or, for a native shibboleth SP inside of Rails (http://support.onelogin.com/entries/165434-saml-toolkit-for-ruby-on-rails).

Great work as I know there are a few Shiro users out there, and if they can get Shibboleth running in their Grails app while still using the security framework they are familiar with, you'll have some happy campers.

--
Aaron

[Bradley Beddoes-2]

Hi,

Comments inline.

On 26/06/2012, at 1:55 PM, aaronzirbes wrote:

Hi Bradley,

It's good to see someone integrating Shibboleth into another Grails security
framework!

As the author of the spring-security-shibboleth-native-sp plugin, I hope
you'll take a suggestion.

1st is a heads up that Shibboleth isn't the only federated sign-on system
and it looks like your plugin only ties in to shibboleth.

Yep there are a number of standards in the same space, I've worked with many of them. While the internals of the plugin

have no direct links to Shibboleth and are generic enough to be used with any implementation

that provides header/env-var identity values having handled specifics of authentication the folks who funded this

development primarily utilise/support Shibboleth SP so it is important for their user base that this is heavily highlighted.

2nd, Your plugin doesn't directly implement the SAML2 protocol, and requires
the Apache mod_shibXX libraries, which are referred to as the "Shibboleth
Native SP".  Not all frameworks require this (mine does, just like yours),
so it'd be nice to see this referred to as the "Shibboleth Native SP", as
"Shibboleth SP" can refer to anything implementing itself as a service
provider.  A link to the "Shibboleth Native SP" would also help folks get
what they need rather than just referring to it by name.  Here's my link:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfiguration

I'm not sure of the relevance of this point. The shibboleth folk clearly market their

SAML service provider implementation as the "The Shibboleth Service Provider" http://shibboleth.net/products/service-provider.html 

I'm aware that the Native term is used in a lot of the technical documentation to be correct to the OS/Web Server tie in it provides but I've

not in my experience heard anyone implementing a service refer to the technology in that way.

The generic term for an application participating in a SAML federation is a Service Provider or SP. There are several other

technical implementations of the SAML 1/2 standards (commercial and open source) that a service provider could choose to use besides the Shibboleth service provider to present itself to a federation. Thus I'm not quite sure then what you mean by "Shibboleth SP can refer to anything implementing itself as a service provider".

I have however updated the documentation to link back to the Shibboleth website as you've suggested, this is a good idea.

As a side note, I also would have liked to see "shibboleth" in the plugin
title.  "shiro" in the title would have been nice as well.   Also using the
word 'grails' in a Grails plugin is a bit redundant.  I know it's probably
too late.

Please see the above discussion in this thread about naming and funding.

I know you mentioned Rails, so if it helps, there is already a Rails plugin
for Shibboleth that's really nice.
(https://github.com/jgeorge300/devise_shibboleth_authenticatable).  Or, for
a native shibboleth SP inside of Rails
(http://support.onelogin.com/entries/165434-saml-toolkit-for-ruby-on-rails).

Yes we also have one that I wrote a while back, which is probably due for a revisit, https://github.com/ausaccessfed/federatedrails that

tries to keep the concepts the same between technologies. Our plan is to continue to do that so moving between technologies when developing federated applications remains at least somewhat familiar for developers.

cheers,

Bradley