The thing I like about this approach is that we've figured out a way to cleanly marry basic auth (which is critical for programmatic HTTP access) and auth via a form, which is important for nice UI access. Very cool.

Deepal- can you send a note to abdera-dev about the lack of HTTP session support and ask whether they have plans to implement it? Its really simple to do it .. so if they're not doing it we can do it and give a patch. Let's go ahead by implementing it with by sending the Authorization header each time, but that's expensive on the server side as we'll have to re-authenticate every single time.

Sanjiva.

Deepal Jayasinghe wrote:
Hi all,

In our APP implementation does not have authorization  support and we
need to implement that before the next release as well. So today we
(Sanjiva , Chathura and I ) discussed about this can came up with the
following general approach for the authorization.

Web app  (/web)
==============
  - When we use this user is supposed to login in the registry and once
the user login in the registry we create a secure registry. If the user
does not login  in to the system then we treat the user as a the
"anonymous" user. No matter what when we use the web application we will
have the session object associate with the user and depending on the
user role and role authorization  we can  control the user action. (For
example if the user tries to perform an action which is not authorized
to him then will throw an exception)

Accessing resource content (/resource/a/ab/c)
================================
  - Here there are two approaches , first user tries to access a
resource while he is having a valid session (meaning that he has login
in the system using the web app). Then once he type the URL in the
browser then if the user is authorized to access the resource then he
will be able to access the resource , else he will get HTTP 401
 - Second  when user try to browse the resource without login , then the
content will be shown if the user is authorized to do so , else he will
be giving a HTTP 401 with the challenge (asking to give the username and
the password). If he does then at the server (servlet) will create a
secure registry for that and handle the request.
APP (/atom)
============
In this case if the user want to make the communication secure , (s)he
can turn on the HTTPS in the serer side and provide the relevant data to
the registry to send the user credential.

Second we can send the username and the password in the request as the
authentication headers and retrieve that from the server side and create a secure registry for the user. To implement this I looked in to
abdera and found that we can send a header called "Authorization" and
access that at the server side. However abdera does not have a way to
give or retrieve the cookies, therefore we can not completely rely on
abdera session management support. As a result of that we need to send
this authorization header in each requests. I will implement the APP
authorization support based on this approach and commit the code so that
we can comment on that.

-Deepal


_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev


--
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
email: [EMAIL PROTECTED]; cell: +1 650 265 8311 | +94 77 787 6880

"Oxygenating the Web Service Platform."

_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev

Reply via email to