Using Roles and LIftRules.authentication

[glenn]

I'm looking for direction on the best pattern for implementing basic
authentication and authorization in Lift.
For example, if I already have a Role mapper to store roles in the
database, to what do I attach the Role trait in
the net.liftweb.http.auth package?

1) The mapper. You would have to make sure there were no naming
conflicts ( i.e., def name in the trait and the mapped string, name,
in the mapper. Not the best design pattern to link the two, in my
humble opinion.)

or

2) A new class, or perhaps an object, with the trait that wraps a Role
mapper instance.

The other piece to the puzzle is managing the list of AuthRoles,
create protected resources and build the Lift.authentication cases. If
you limit this to Boot, then you give up on dynamic authentication and
authorization, or do you?

Glenn...

[Timothy Perrett]

Glenn,

If Marius doesn't beat ne to it, I'll reply tomorrow morning. The
system we implemented for auth was not meant to be composed with
matter per-say, not in the way you think however...

Presumably you've looked at the http Auth example in the github repo?
I'm not sure why on earth you would think it's not possible to do
dynamic auth with the existing system? Of course it is!

Cheers

Tim

Sent from my iPhone

[glenn]

Tim,
I tend to agree with you that the Role trait is not a good mixin for a
role mapper, which is why
I raise the question.

Maybe I'm looking in the wrong place, but the http-authentication
example in liftweb.sites on github
doesn't have much code. The LiftBook is a more complete example. And
neither deals with useage
of the Role trait, nor with persisting authorization info. Is there
some other example I should be looking at?

On the issue of dynamic auth, the examples I've seen all run in Boot
which leaves open
the question of how to manage the same thing on the fly, so to speak,
not that it can't be
done. You guys have done too good a job on Lift to have overlooked
that.

Glenn...

[Charles F. Munat]

There is a big difference between "authentication" (making sure someone
is who they claim to be) and "authorization" (making sure that now that
we know who they are, they have permission to do what they're trying to do).

It seems to me that what you're referring to is a Role-Based Access
Control (RBAC) system. And when you say "dynamic," I believe that what
you mean is that you will keep users, roles, and permissions in a
database where they can be easily changed rather than hard-coded in Lift.

I could be wrong, but I am pretty sure that Lift offers no such system
and you'll have to roll your own. I need to do this myself, and I'm
interested in control down to individual properties and methods in
system objects. So I'd be very interested in anything you (or anyone
else) comes up with.

Chas.

[marius d.]

I'll let Tim provide you a concrete code example but AFAIK there is a
lift-authetication example in examples?

A few points:

1. We support both BASIC and DIGEST HTTP authentication
2. First, to apply authentication you need to specify which resource
(by URI) is a protected resource. Here we say that resource X is
protected by Role A (Roles are hierarchicaly structured)
3. Secondly you set up the authentication function in Boot (for Basic
or Digest) you check the credentials. If authentication succeeds that
request is being processed.

Here is an example from lift-authentication:

LiftRules.httpAuthProtectedResource.prepend {
case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
Full(AuthRole("admin"))
}
// This resource is protected by an AuthRole named admin.

LiftRules.authentication = HttpBasicAuthentication("lift") {
case ("someuser", "1234", req) => {
Log.info("You are now authenticated !")
userRoles(AuthRole("admin"))
true
}
}

When we try to access /secure-basic resource HTTP basic auth. is
applied. If
credentials are correct we set the AuthRole as admin on the
Requestvar
userRoles. If we would have set another role such as userRoles
(AuthRole
("guest")) the resource would still not be served as guest has nothing
to do with
an admin. The lift-book describes the rules of Roles application.

All this has nothing to do with Mapper or Record etc. it is purely
about HTTP authentication and a simple authorization mechanism


Br's,
Marius

[glenn]

[glenn]

Marius,

I appreciate your reply, but the question I asked regards useage of
the Role trait in what Charles
refers to as a Role-Based Access Control (RBAC) system. I could not
find this addressed in the
Lift Book and, no, there is no illuminating code in the lift-
authentication example. It's established
the trait is not a good mixin for a mapper class in maintaining
persistent role/access
data. I was asking, on a lark, if anyone had ideas on a pattern that
might help. I guess
I've gotten an answer - No.

I certainly don't expect Lift, out-of-the-box, to provide a complete
authorization package
and I would have been surprised if it had.

Glenn...

On Sep 5, 12:38 am, "marius d." <marius.dan...@gmail.com> wrote:

[Timothy Perrett]

Glenn, its simply not designed to do what your asking - however, the
most "lift way" of doing access control is with SiteMap, so
potentially look into that as a solution. You don't detail your needs,
but we've had this conversation several times on-list so just look
through the archives and that might spawn some other ideas for you.

Tim

PS: Is there any good reason you always put an ellipsis after your
name? For some reason it bothers me quite a bit!

[marius d.]

Glen,

Tim is correct however HTTP auth support + it's Role model can be used
for SiteMenu as well. Please see:

case class HttpAuthProtected(role: () => Box[Role]) extends LocParam

You easily can specify that a Loc is a protected resource you just
need to return the Role that guards this resource. This Loc will be
served only if HTTP authentication succeeds and the Role match.

So this is an RBAC.

Br's,
Marius

[Timothy Perrett]

Right, i know it has a sitemap aspect... just based on what chas has
asked about RBAC before, I can only presume he's still looking for
more granularity than sitemap offers :-)

Perhaps it might work for Glenn though...

Cheers, Tim

[glenn]

Marius,

In practical terms, if I am already using an If LocParam, as in the
following:

If(() => User.isa_?("admin"), S.?("not_authorized"))

what does adding

HttpAuthProtected(() => User.authorize("admin")) to the Loc do?

Here, I've had to define User.authorize to make things work, as:

def authorize(roleName:String): Box[Role] = {
val credentials : (String,String) = User.currentUser match {
case Full(u) => (u.email.is, u.password.is)
case Empty => (null, null)
}

User.isa_?(roleName) match {
case true => {
LiftRules.httpAuthProtectedResource.append {
case (ParsePath("listContents" :: _, _, _, _)) => Full
(AuthRole("admin"))

}
LiftRules.authentication = HttpBasicAuthentication("lift")
{

case (credentials._1, credentials._2, req) =>
AuthRole(roleName)
true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false => Empty
}

Rather verbose, don't you think.

elipsisless Glenn

[glenn]

Tim,

You are right. Protecting resources and menu items is well documented
in Lift. But providing read/write permissions, and even restricting
access to
specific data entities based on a subject's role, if that's what you
mean by
more granularity, is often a required use case in an application.

Dividing up read-only views and editable templates into different
resources helps. And limiting data access is certainly doable. It
would just
be nice to centralize some of these features, and that's what I'm
trying achieve in my
code.

Glenn . - oops, I almost lost myself there.

[marius d.]

On Sep 7, 10:53 pm, glenn <gl...@exmbly.com> wrote:
> Marius,
>

> In practical terms, if I am already using an If LocParam, as in the
> following:
>
> If(() => User.isa_?("admin"), S.?("not_authorized"))
>
> what does adding
>
> HttpAuthProtected(() => User.authorize("admin")) to the Loc do?

It sais that this Loc is protected by the returned Role. Thus to
access this after passing the authentication the Role specified in the
authentication function (by setting userRoles) must be the same as or
a child of the Role the is protecting the Loc.

>
> Here, I've had to define User.authorize to make things work, as:
>
>  def authorize(roleName:String): Box[Role] =  {
>       val credentials : (String,String) = User.currentUser match {
>           case Full(u) => (u.email.is, u.password.is)
>           case Empty => (null, null)
>       }
>
>       User.isa_?(roleName) match {
>         case true => {
>             LiftRules.httpAuthProtectedResource.append {
>                 case (ParsePath("listContents" :: _, _, _, _)) => Full
> (AuthRole("admin"))
>             }

Why do you need to use httpAuthProtectedResource if you' using
HttpAuthProtected LocParam ?

>             LiftRules.authentication = HttpBasicAuthentication("lift")
> {
>                 case (credentials._1, credentials._2, req) =>
>                         AuthRole(roleName)
>                         true
>             }
>             Full(new _root_.net.liftweb.http.auth.Role{
>                         def name = roleName})
>             }
>       case false => Empty
>     }
>
> Rather verbose, don't you think.

Your code is verbose but I don't see the justification for this
verbosity:

LiftRules.authentication = HttpBasicAuthentication("lift") {

case (username, password, req) => {
// Do you authentication in DB or whatever and you
determined that this is an admin user
userRoles(AuthRole("admin")) // userRoles needs to be
set. It is a RquestVar.
true
}

In Boot you have:

Menu(Loc("listContents", List("listContents"), "listContents",
HttpAuthProtected(() => Full(AuthRole("admin")))))

When you use HttpAuthProtected LocParam Lift appends a function to
LiftRules.httpAuthProtectedResource so you don't need to do it
manually.

This authorixation scheme is only about protecting resource by roles
and you do this almost declaratively and for authentication I thing
the things are pretty straight forward. One a user is authenticated
(using HTTP authentication) you need to specify the Role for this user
and you do this using userRoles RequestVar.Thus /listContents can only
be accessed if:

1. user passed authentications
2. user's Role is an "admin" or a child of the Role specified in
HttpAuthProtected

[glenn]

Marius,

Please bear with me. I'm a little slow in following the logic here.

I understand I can protect the resource as you suggest from all
but users with admin roles, using the LocParam,

HttpAuthProtected(() => Full(AuthRole("admin"))))) .

Now, when I click on the link, if no user is logged in, the system
asks for a username and password to connect, but that's a user
on the host. not an application user. Somewhere, I need to assign the
currently logged in user the AuthRole("admin") needed to access
the resource.

Seems to me I need code like this to run someplace:

def authorize(roleName:String): Box[Role] = {

object userRoles extends RequestVar[Role](null)

val credentials : (String,String) = User.currentUser match {
case Full(u) => (u.email.is, u.password.is)
case Empty => (null, null)
}

User.isa_?(roleName) match {
case true => {

LiftRules.authentication = HttpBasicAuthentication("lift")
{
case (credentials._1, credentials._2, req) =>

println("John is authenticated!")
userRoles(_root_.net.liftweb.http.auth.AuthRole
(roleName))

true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false => Empty
}
}

Can't be in Boot,

Glenn

[marius d.]

On Sep 8, 1:18 am, glenn <gl...@exmbly.com> wrote:
> Marius,
>
> Please bear with me. I'm a little slow in following the logic here.

Don't worry glen.

>
> I understand I can protect the resource as you suggest from all
> but users with admin roles, using the LocParam,
>
> HttpAuthProtected(() => Full(AuthRole("admin"))))) .
>
> Now, when I click on the link, if no user is logged in, the system
> asks for a username and password to connect, but that's a user
> on the host. not an application user.

Not necessarily. It is any type of user. In your authentication
function you can go in DB and validate the receiving credentials as

application user.

> Somewhere, I need to assign the
> currently logged in user the AuthRole("admin") needed to access
> the resource.

Correct. And you dothis by setting userRoles RequestVar.

>
> Seems to me I need code like this to run someplace:
>
> def authorize(roleName:String): Box[Role] = {
>       object userRoles extends RequestVar[Role](null)
>
>       val credentials : (String,String) = User.currentUser match {
>           case Full(u) => (u.email.is, u.password.is)
>          case Empty => (null, null)
>       }
>
>       User.isa_?(roleName) match {
>         case true => {
>             LiftRules.authentication = HttpBasicAuthentication("lift")
> {
>                 case (credentials._1, credentials._2, req) =>
>                         println("John is authenticated!")
>                         userRoles(_root_.net.liftweb.http.auth.AuthRole
> (roleName))
>                         true
>             }
>             Full(new _root_.net.liftweb.http.auth.Role{
>                         def name = roleName})
>             }
>       case false => Empty
>     }
>  }
>
> Can't be in Boot,

No you do not. Lift takes care of the roles matching for you. You
don't need to manually test if a user is-an admin or some other role
in order to access that resource. Please keep in mind that is just for
accessing resources (URI-s) if you need to do more complex logic in
your code and see if the user is an admin or having some other Role
that you'd probably need to save the Role into a SessionVar or into
your User object.

All I want here is to explain how HTTP based authentication and roles
based authorization works. I am definitely not claiming that this is
enough for all applications as currently we don't have HTTP based
authentication with forms for example ... but I think we should add
that as well.

> ...
>
> read more »

[glenn]

Marius,

With your help, I think I'm getting closer to understanding what is
needed
here.

One thing though, is that I believe I do need to manually check if the
user has the
appropriate role (in the DB) before I can set userRoles RequestVar.
See, in my application,
I have no way of knowing in advance if a logged-in user is authorized
to access
a particular resource. I'm trying to accomplish that programatically.
And, don't forget, roles
can be changed at any time in the application. In other words, I
can't just assume it in my
authentication function and make the assignment there.

Does that make sense? This is not to say that I can't work
tangentially to Http basic authentication
in Lift and create my own, just that I'm trying to incorporate the
work already done so I don't have to.

Glenn

> ...
>
> read more »

[marius d.]

On Sep 8, 6:12 pm, glenn <gl...@exmbly.com> wrote:
> Marius,
>

> With your help, I think I'm getting closer to understanding what is
> needed
> here.
>
> One thing though, is that I believe I do need to manually check if the
> user has the
> appropriate role (in the DB) before I can set userRoles RequestVar.
> See, in my application,
> I have no way of knowing in advance if a logged-in user is authorized
> to access
> a particular resource. I'm trying to accomplish that programatically.

Well if when authenticating a user (LiftRules.authentication) you
can't determine the Role, then this mechanism probably won't help you
and you need to build your own.

> And, don't forget, roles
> can be changed at any time in the application.

I assume that a "super-admin" user would be able to change roles for
other users right? ... If so you just need to update data in your DB
for say user X. So when User X authenticates you'll get the new role
assigned. But maybe this is not how your app is designed to work.

> In other words, I
> can't just assume it in my
> authentication function and make the assignment there.
>
> Does that make sense?  This is not to say that I can't work
> tangentially to Http basic authentication
> in Lift and create my own, just that I'm trying to incorporate the
> work already done so I don't have to.

Lift's HTTP authentication and authorization is built on very simple
principles such as:

1. In the authentication function you typically know the role for that
user.
2. Resources (URI's essentially) are protected by hierarchically
structured roles that are matched with the role determined by the
authentication function.

> ...
>
> read more »

[glenn]

Marius,

I guess there is little more to be said on this issue. Keep in mind
that
in many real-world applications, dynamically assigned user roles are a
requirement. And it's possible for users to have multiple roles, each
in a different role hierarchy, in the same application.

Inevitably, I will have to implement my own, perhaps using
JaaS or one of its variants. If you have any thoughts on that issue,
I'd like to hear them.

Thanks,

Glenn

> ...
>
> read more »

[marius d.]

On Sep 8, 7:00 pm, glenn <gl...@exmbly.com> wrote:
> Marius,
>

> I guess there is little more to be said on this issue. Keep in mind
> that
> in many real-world applications, dynamically assigned user roles are a
> requirement. And it's possible for users to have multiple roles, each
> in a different role hierarchy, in the same application.

Well Lift Roles are build on hierarchical model.

>
> Inevitably, I will have to implement my own, perhaps using
> JaaS or one of its variants. If you have any thoughts on that issue,
> I'd like to hear them.

I kind of doubt that JAAS will take you farther then Lift HTTP auth
support.

> ...
>
> read more »