Grails Plugin external authentication

[Edvinas Bartkus-2]

Hello,

I am writing grails plugin to have forum inside your grails
application. I would like not to use any internal authentication
because i believe everyone would have their own implementation how the
users authenticate. Do you have any suggestions what would be the best
way to integrate external authentication method? Maybe there is
existing plugin to see an example?

Edvinas

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

    http://xircles.codehaus.org/manage_email

[tinny]

The spring security plugin can use the request map approach for securing URL's.

http://www.grails.org/AcegiSecurity+Plugin+-+Securing+URLs

Because URL's are being secured the user will not need to touch the
source code for your plugin. If the user was using the annotations
approach (my preferred) then they would need to append to your plugins
code.

These are just two of the many security approaches available for Grails.

On Mon, Mar 1, 2010 at 3:11 AM, Edvinas Bartkus <[hidden email]> wrote:

> Hello,
>
> I am writing grails plugin to have forum inside your grails
> application. I would like not to use any internal authentication
> because i believe everyone would have their own implementation how the
> users authenticate. Do you have any suggestions what would be the best
> way to integrate external authentication method? Maybe there is
> existing plugin to see an example?
>
> Edvinas
>
> ---------------------------------------------------------------------
> 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

[Edvinas Bartkus-2]

Yes. However, the plugin needs to know who is the author of the post,
who has permission to edit and so on. Is it possible to implement
somehow universal system that would work?

I believe having clear solution for this situation would be possible
to write more great plugins who would provide working parts for the
application.

My idea is to have an interface that must be implemented to have the
plugin working. Interface would require to have main methods to get
current user, to know what is the class of User object and etc.
Is there a more convenient over configuration solution?

Edvinas

On Sun, Feb 28, 2010 at 10:57 PM, Sean Tindale <[hidden email]> wrote:

> The spring security plugin can use the request map approach for securing URL's.
>
> http://www.grails.org/AcegiSecurity+Plugin+-+Securing+URLs
>
> Because URL's are being secured the user will not need to touch the
> source code for your plugin. If the user was using the annotations
> approach (my preferred) then they would need to append to your plugins
> code.
>
> These are just two of the many security approaches available for Grails.
>
> On Mon, Mar 1, 2010 at 3:11 AM, Edvinas Bartkus <[hidden email]> wrote:
>> Hello,
>>
>> I am writing grails plugin to have forum inside your grails
>> application. I would like not to use any internal authentication
>> because i believe everyone would have their own implementation how the
>> users authenticate. Do you have any suggestions what would be the best
>> way to integrate external authentication method? Maybe there is
>> existing plugin to see an example?
>>
>> Edvinas
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[pledbrook]

> I believe having clear solution for this situation would be possible
> to write more great plugins who would provide working parts for the
> application.
>
> My idea is to have an interface that must be implemented to have the
> plugin working. Interface would require to have main methods to get
> current user, to know what is the class of User object and etc.
> Is there a more convenient over configuration solution?

It has been suggested that Grails has a defined security API that the
different plugins can implement. That would probably be ideal for you,
but nothing has been done yet. Any one fancy starting a Security API
Working Group?

Cheers,

Peter

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

    http://xircles.codehaus.org/manage_email

[Edvinas Bartkus-2]

It would open doors for richer grails plugins for sure. However, is it
possible to have such an API and would other security plugins accept
the API?

As I understand it is the big inner Grails thing and only possible
with core team support. What were the pros and cons?

Edvinas

On Mon, Mar 1, 2010 at 11:38 AM, Peter Ledbrook <[hidden email]> wrote:

>> I believe having clear solution for this situation would be possible
>> to write more great plugins who would provide working parts for the
>> application.
>>
>> My idea is to have an interface that must be implemented to have the
>> plugin working. Interface would require to have main methods to get
>> current user, to know what is the class of User object and etc.
>> Is there a more convenient over configuration solution?
>
> It has been suggested that Grails has a defined security API that the
> different plugins can implement. That would probably be ideal for you,
> but nothing has been done yet. Any one fancy starting a Security API
> Working Group?
>
> Cheers,
>
> Peter
>
> ---------------------------------------------------------------------
> 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

[bzarzoza]

> Any one fancy starting a Security API Working Group?

Yes. I think that offering an out-of-the-box Security API would make Grails a far more attractive framework. I would love to help in any way possible.

-Brandon Zarzoza

[cazacugmihai]

+1

On Mon, Mar 1, 2010 at 2:34 PM, Brandon Zarzoza <[hidden email]> wrote:

> Any one fancy starting a Security API Working Group?

Yes. I think that offering an out-of-the-box Security API would make Grails a far more attractive framework. I would love to help in any way possible.

-Brandon Zarzoza

--
-----------------------------------
Mihai Cazacu
Software Engineer
E-mail: [hidden email]
Mobile: [phone]

[Edvinas Bartkus-2]

I could write a proposition as Google Summer Of Code project. I could
do some good work if project would have support from everyone.

Edvinas

On Mon, Mar 1, 2010 at 2:34 PM, Brandon Zarzoza <[hidden email]> wrote:
>> Any one fancy starting a Security API Working Group?
>
> Yes. I think that offering an out-of-the-box Security API would make Grails
> a far more attractive framework. I would love to help in any way possible.
>
> -Brandon Zarzoza
>

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

    http://xircles.codehaus.org/manage_email

[cazacugmihai]

I can offer my help in this case.

On Mon, Mar 1, 2010 at 2:52 PM, Edvinas Bartkus <[hidden email]> wrote:

I could write a proposition as Google Summer Of Code project. I could
do some good work if project would have support from everyone.

Edvinas

On Mon, Mar 1, 2010 at 2:34 PM, Brandon Zarzoza <[hidden email]> wrote:
>> Any one fancy starting a Security API Working Group?
>
> Yes. I think that offering an out-of-the-box Security API would make Grails
> a far more attractive framework. I would love to help in any way possible.
>
> -Brandon Zarzoza
>

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

   http://xircles.codehaus.org/manage_email

--
-----------------------------------
Mihai Cazacu
Software Engineer
E-mail: [hidden email]
Mobile: [phone]

[Daniel Honig]

You might have a look at the Taggable, Rateable or Commentable plugins.

These plugins use a  closure to evaluate the current user.  You could
use the same approach in your plugin

(That is until there is a defined security api)

On Sun, Feb 28, 2010 at 9:11 AM, Edvinas Bartkus <[hidden email]> wrote:

> Hello,
>
> I am writing grails plugin to have forum inside your grails
> application. I would like not to use any internal authentication
> because i believe everyone would have their own implementation how the
> users authenticate. Do you have any suggestions what would be the best
> way to integrate external authentication method? Maybe there is
> existing plugin to see an example?
>
> Edvinas
>
> ---------------------------------------------------------------------
> 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

[Edvinas Bartkus-2]

Thanks. For now I will stick with *able plugins methodology to deal
with authentication :) Probably I should call the plugin Forumable :P

Edvinas

On Mon, Mar 1, 2010 at 3:20 PM, Daniel Honig <[hidden email]> wrote:

> You might have a look at the Taggable, Rateable or Commentable plugins.
>
> These plugins use a  closure to evaluate the current user.  You could
> use the same approach in your plugin
>
> (That is until there is a defined security api)
>
> On Sun, Feb 28, 2010 at 9:11 AM, Edvinas Bartkus <[hidden email]> wrote:
>> Hello,
>>
>> I am writing grails plugin to have forum inside your grails
>> application. I would like not to use any internal authentication
>> because i believe everyone would have their own implementation how the
>> users authenticate. Do you have any suggestions what would be the best
>> way to integrate external authentication method? Maybe there is
>> existing plugin to see an example?
>>
>> Edvinas
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[pledbrook]

> It would open doors for richer grails plugins for sure. However, is it
> possible to have such an API and would other security plugins accept
> the API?
>
> As I understand it is the big inner Grails thing and only possible
> with core team support. What were the pros and cons?

I don't believe that development of a security API requires the
involvement of the core Grails team. All you really want is a standard
specification split between authentication and authorisation that fits
the needs of 80% of users. Security plugins could then implement
either the authentication part, the authorisation part, or both.

Of course, if someone gets this ball rolling, you'll need the
involvement of the main security plugin authors: Burt Beckwith, Marc
Palmer, and myself. If I missed anyone of that list, apologies.

I suggest potential discussions take part on the grails-dev list with,
say "WG-SEC" in the subject, or something like that.

Cheers,

Peter

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

    http://xircles.codehaus.org/manage_email

[Marc Palmer Local]

On 1 Mar 2010, at 12:52, Edvinas Bartkus wrote:

> I could write a proposition as Google Summer Of Code project. I could
> do some good work if project would have support from everyone.
>

My view on this, from a previous post:

http://www.pubbs.net/grails/200910/34895/


...and here is the kind of thing we are using in WeceemSecurityService:

   
    /**
     * Applications set this to an object implementing these methods
     */
    def securityDelegate = [
        getUserName : { -> "unknown" },
        getUserEmail : { -> "unknown@localhost" },
        getUserPrincipal : { -> [id:'unknown', name:'unknown', email:"unknown@localhost"] },
        getUserRoles: { -> ['ROLE_ADMIN'] }
    ]

Obviously this could use a bean / service instead eg (ApplicationSecurityService - provided by the app / plugin) but this gives the best of both worlds - application can wire it up how it likes, possibly even supporting multiple security mechanisms.

There is some duplication above there, but it is just an example.

Weceem is completely authentication-neutral, you just set up that delegate to call whatever library you use.

Marc


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

    http://xircles.codehaus.org/manage_email

[Shane Petroff]

Marc Palmer wrote:
>
> My view on this, from a previous post:
>
> http://www.pubbs.net/grails/200910/34895/
>  

I agree, being overly prescriptive ends up annoying too many people, in
addition to complicating the core.



>     def securityDelegate = [
>         getUserName : { -> "unknown" },
>         getUserEmail : { -> "unknown@localhost" },
>         getUserPrincipal : { -> [id:'unknown', name:'unknown', email:"unknown@localhost"] },
>         getUserRoles: { -> ['ROLE_ADMIN'] }
>     ]
>  

So would the delegate simply be injected via Spring, or whatever
metaclass mechanism Grails uses for things like errors objects?
How are you handling authorization hooks or is it a simple hasRole(role)?

--
Shane


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

    http://xircles.codehaus.org/manage_email

[Marc Palmer Local]

On 1 Mar 2010, at 21:11, Shane Petroff wrote:

> Marc Palmer wrote:
>>
>> My view on this, from a previous post:
>>
>> http://www.pubbs.net/grails/200910/34895/
>>  
>
> I agree, being overly prescriptive ends up annoying too many people, in addition to complicating the core.
>
>
>
>>    def securityDelegate = [
>>        getUserName : { -> "unknown" },
>>        getUserEmail : { -> "unknown@localhost" },
>>        getUserPrincipal : { -> [id:'unknown', name:'unknown', email:"unknown@localhost"] },
>>        getUserRoles: { -> ['ROLE_ADMIN'] }
>>    ]
>>  
>
> So would the delegate simply be injected via Spring, or whatever metaclass mechanism Grails uses for things like errors objects?
> How are you handling authorization hooks or is it a simple hasRole(role)?
>

In weceem that delegate is a field of WeceemSecurityService. So you look up the bean and wire in your own delegate.

We will probably change this to look for a spring bean first, and if there is none, delegate to a the above. That way we get the best of both worlds and backward compatibility.

Marc


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

    http://xircles.codehaus.org/manage_email

[Marc Palmer Local]

On 1 Mar 2010, at 16:00, Peter Ledbrook wrote:

>> It would open doors for richer grails plugins for sure. However, is it
>> possible to have such an API and would other security plugins accept
>> the API?
>>
>> As I understand it is the big inner Grails thing and only possible
>> with core team support. What were the pros and cons?
>
> I don't believe that development of a security API requires the
> involvement of the core Grails team. All you really want is a standard
> specification split between authentication and authorisation that fits
> the needs of 80% of users. Security plugins could then implement
> either the authentication part, the authorisation part, or both.
>
> Of course, if someone gets this ball rolling, you'll need the
> involvement of the main security plugin authors: Burt Beckwith, Marc
> Palmer, and myself. If I missed anyone of that list, apologies.
>
> I suggest potential discussions take part on the grails-dev list with,
> say "WG-SEC" in the subject, or something like that.
>

I agree with the sentiment about a convention, but I disagree that grails core should not be involved.

Out of the box grails should provide dynamic methods/properties to access auth information, and util classes for accessing it according to the contract specification we come up with, from outside artefacts.

Eg controllers could have the following added dynamically by a "grails-auth" core plugin:

r/o property: userName
r/o property: userEmail
r/o property: userRoles
r/o property: userPrincipal

method: userLogOut()
method: userIsPermitted(somePermissionObject, Closure = null)

Other artefacts/classes would be able to access these via an AuthenticationDataHolder that hides the details of how this stuff is provided by the underlying plugin implementing it all.

By putting the impl for this in grails we make the specification solid and avoid problems with divergent implementations - if you don't supply the right info to the core grails code, then -you- are broken. :)

This also means that any such helper code is safely in the org.grails namespace etc.

My $0.02

Marc
~ ~ ~
Marc Palmer
Blog         > http://www.anyware.co.uk
Twitter      > http://twitter.com/wangjammer5
Grails Rocks > http://www.grailsrocks.com







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

    http://xircles.codehaus.org/manage_email

[Edvinas Bartkus-2]

Can we move this discussion to dev list? I think it is high time to
have some implementation for Security API or smt like that.

Edvinas

On Mon, Mar 1, 2010 at 11:46 PM, Marc Palmer <[hidden email]> wrote:

>
> On 1 Mar 2010, at 16:00, Peter Ledbrook wrote:
>
>>> It would open doors for richer grails plugins for sure. However, is it
>>> possible to have such an API and would other security plugins accept
>>> the API?
>>>
>>> As I understand it is the big inner Grails thing and only possible
>>> with core team support. What were the pros and cons?
>>
>> I don't believe that development of a security API requires the
>> involvement of the core Grails team. All you really want is a standard
>> specification split between authentication and authorisation that fits
>> the needs of 80% of users. Security plugins could then implement
>> either the authentication part, the authorisation part, or both.
>>
>> Of course, if someone gets this ball rolling, you'll need the
>> involvement of the main security plugin authors: Burt Beckwith, Marc
>> Palmer, and myself. If I missed anyone of that list, apologies.
>>
>> I suggest potential discussions take part on the grails-dev list with,
>> say "WG-SEC" in the subject, or something like that.
>>
>
> I agree with the sentiment about a convention, but I disagree that grails core should not be involved.
>
> Out of the box grails should provide dynamic methods/properties to access auth information, and util classes for accessing it according to the contract specification we come up with, from outside artefacts.
>
> Eg controllers could have the following added dynamically by a "grails-auth" core plugin:
>
> r/o property: userName
> r/o property: userEmail
> r/o property: userRoles
> r/o property: userPrincipal
>
> method: userLogOut()
> method: userIsPermitted(somePermissionObject, Closure = null)
>
> Other artefacts/classes would be able to access these via an AuthenticationDataHolder that hides the details of how this stuff is provided by the underlying plugin implementing it all.
>
> By putting the impl for this in grails we make the specification solid and avoid problems with divergent implementations - if you don't supply the right info to the core grails code, then -you- are broken. :)
>
> This also means that any such helper code is safely in the org.grails namespace etc.
>
> My $0.02
>
> Marc
> ~ ~ ~
> Marc Palmer
> Blog         > http://www.anyware.co.uk
> Twitter      > http://twitter.com/wangjammer5
> Grails Rocks > http://www.grailsrocks.com
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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