Restful Authorisation

[Samuel Richardson]

I'm in the process of implementing an authorisation system. I don't think the system is that complex but the underlying technology we're running on is not your typical Rails site. Essentially our setup is:

Various Apis

     |

NodeJS Server

     |

Client Computers

Various APIs do the work and on database updates, send the update to the Node Server. The Node server broadcasts the changes to the clients and the clients are your typical web browsers on the website getting realtime updates of what's happening in the APIs. Requests to change information go via the Node server as well.

I have authentication working well. However, I need to implement authorisation at some layer in this stack, either the at the NodeJS level or at each individual API. The auth will also be attached to a user which is available from the Users API.

I've got a few ideas of how to go about this, but wondered if anybody had implemented something similar? My guess is to implement at the Node level and before any requests which require auth, query against the users api asking them if the action is allowed. However, it might be easier to implement at a per API level via a shared gem etc.

Samuel Richardson
www.richardson.co.nz | 0405 472 748

[Nicholas Faiz]

Hi,

In a recent project we created an authentication and authorization API that ran separately to the main app., and it ended up being my ideal way of handling it (for an app that has belong to to an organisation of any significant size). This turned out to be a great way of doings things for SSO and role clarification (instead of every app inventing its understanding of roles, there was a centralised 'source of truth' for them which client apps leveraged).

So, I would probably make the Node.js app a client of the Authentication/Authorisation API. You have a nice breakup of services already, so I think it'd be a mistake to bake it into the Node layer.

Cheers,

Nicholas

[Samuel Richardson]

Hmm, I wasn't clear enough. The auth would occur as a separate API but be primarily called from NodeJS layer rather then at each API's layer.

How did you handle structuring the rules?

Samuel Richardson
www.richardson.co.nz | 0405 472 748

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/1sP6-7s3TDsJ.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

[Nicholas Faiz]

Sure, but none of that is an argument to confuse the role of what the node layer is doing.

Authorisation is about checking the permissions someone has against what the permissions to do something requires. That's usually expressed as a role (could be a group of permissions though). The most sensible place to explain what roles/perms a user has is in the handback from an authentication system, I think.

Not sure what you mean about structuring the rules. It was a role based authorisation scheme, so they were just names (admin, editor, etc.) associated with a user by someone through a web UI. Then it was simply a role check on the spot, in the client app, to see if the user was authorised. If that qualifies as rule based programming it wasn't very complex.

Anyway, cheers,

Nicholas

On Wednesday, February 29, 2012 10:38:31 AM UTC+11, Samuel Richardson wrote:

Hmm, I wasn't clear enough. The auth would occur as a separate API but be primarily called from NodeJS layer rather then at each API's layer.

How did you handle structuring the rules?

Samuel Richardson
www.richardson.co.nz | 0405 472 748

To unsubscribe from this group, send email to rails-oceania+unsubscribe@googlegroups.com.

[Tim Uckun]

On Wed, Feb 29, 2012 at 12:29 PM, Nicholas Faiz <nichol...@gmail.com> wrote:
> Hi,
>
> In a recent project we created an authentication and authorization API that
> ran separately to the main app., and it ended up being my ideal way of
> handling it (for an app that has belong to to an organisation of any
> significant size). This turned out to be a great way of doings things for
> SSO and role clarification (instead of every app inventing its understanding
> of roles, there was a centralised 'source of truth' for them which client
> apps leveraged).
>

Wouldn't LDAP been a good candidate for something like this?

[Nicholas Faiz]

Sure, but it depends what you want to set up. My client (a sub-org in a university) had a LDAP server in the background doing something. But they wanted this for other reasons (like a sub-organisation). 

[odf]

Hi,

I'm pretty sure I know which project that was. :-) In this case, there
was a legacy system managing the user data which was tied to a
proprietary software package with sometimes very weird restrictions.
So basically, we couldn't get rid of that legacy system and didn't
have the capacity to rewrite it. Instead, we decided to put an API in
front of it that all the new (Rails) components could communicate
with. Like Nick said, it worked quite nicely.

We couldn't have used the existing LDAP system for administrative
reasons, anyway. I guess it would have been possible to set up a
separate one for this particular project, but that would just have
added an extra layer and not really helped much.

That said, I've used LDAP (again an existing installation) in a
different Rails project in the meantime, and found it pretty pleasant
to work with.

Cheers,
Olaf

On Feb 29, 4:52 pm, Nicholas Faiz <nicholas.f...@gmail.com> wrote:
> Sure, but it depends what you want to set up. My client (a sub-org in a
> university) had a LDAP server in the background doing something. But they
> wanted this for other reasons (like a sub-organisation).
>
>
>
>
>
>
>
> On Wednesday, February 29, 2012 3:19:56 PM UTC+11, tim wrote:
>

> > On Wed, Feb 29, 2012 at 12:29 PM, Nicholas Faiz <nicholas.f...@gmail.com>

> > wrote:
> > > Hi,
>
> > > In a recent project we created an authentication and authorization API
> > that
> > > ran separately to the main app., and it ended up being my ideal way of
> > > handling it (for an app that has belong to to an organisation of any
> > > significant size). This turned out to be a great way of doings things for
> > > SSO and role clarification (instead of every app inventing its
> > understanding
> > > of roles, there was a centralised 'source of truth' for them which client
> > > apps leveraged).
>
> > Wouldn't LDAP been a good candidate for something like this?
>
> On Wednesday, February 29, 2012 3:19:56 PM UTC+11, tim wrote:
>

> > On Wed, Feb 29, 2012 at 12:29 PM, Nicholas Faiz <nicholas.f...@gmail.com>