Re: repoze.what -- Authorization for WSGI applications
On Thursday November 27, 2008 11:31:08 Lawrence Oluyede wrote: On Wed, Nov 26, 2008 at 8:03 PM, Gustavo Narea [EMAIL PROTECTED] wrote: Cheers! Slight point about the documentation: you use the same color for hyperlinked text and non-hyperlinked text and I think it somewhat misleading. HTH Thanks, I'll try to correct it asap. -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
On Thursday November 27, 2008 14:13:06 Dalius Dobravolskas wrote: I agree with that. Even more REMOTE_USER is not enough to distinguish between different authentication methods when multiple methods are used. Because of that I offer to do following in r.who: Set REMOTE_USER as username. Usually all authentication systems provides one or another form of username. Set x-wsgiorg.user_data with data dict (e.g. certificate details, OpenID SREG data and etc.). Name was proposed by Ian Bicking. That sounds good to me, but I don't why that's not done. There must be a good reason, I think. This way r.who and r.what will be compatible with other authentication and authorization solutions. Right. :) Cheers. -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
On Thursday November 27, 2008 23:26:06 Graham Dumpleton wrote: Does that mean you ignore AUTH_TYPE variable passed in from Apache where Apache module performs the authentication? repoze.who sets that variable when it performs the authentication. However, if you want to bypass r.who authentication when the server already authenticated the user, you'll have to specify it explicitly (create a rather simple r.who identifier to do so). Cheers. -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
Hello, Gustavo, On the other hand, because REMOTE_USER (which isn't set by r.who) is not always enough and also some of the future features will rely on future/existing repoze.who plugins, for example: I agree with that. Even more REMOTE_USER is not enough to distinguish between different authentication methods when multiple methods are used. Because of that I offer to do following in r.who: Set REMOTE_USER as username. Usually all authentication systems provides one or another form of username. Set x-wsgiorg.user_data with data dict (e.g. certificate details, OpenID SREG data and etc.). Name was proposed by Ian Bicking. This way r.who and r.what will be compatible with other authentication and authorization solutions. -- Dalius http://blog.sandbox.lt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
On Nov 27, 6:03 am, Gustavo Narea [EMAIL PROTECTED] wrote: Hello, everybody. I'm writing to let you know about the authorization framework I have been working on, repoze.what:http://static.repoze.org/whatdocs/ Some of its features are: * Web framework independent. * Authorization only. It will only do authorization and nothing else. * _Highly_ extensible. * _Fully_ documented. * Your application's `groups` and `permissions` may be stored in an SQLAlchemy managed database, thanks to the SQL plugin (repoze.what.plugins.sql). * The only requirement is that you use the repoze.who authentication framework (which is configured for you by repoze.what). Why is it dependent on repoze.who? A nicely decoupled system would only need to know that authentication had succeeded which generally is identifiable by REMOTE_USER being set in the WSGI environment dictionary passed from outer middleware, where outer middleware has performed authentication, or even where it didn't and REMOTE_USER was set by a web server capable of doing authentication itself such as Apache. Graham * It's not hard to get started! It's not a stable software yet, but it's just reached its first beta. Cheers! -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware:http://www.getgnulinux.org/ signature.asc 1KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
Hello, Graham. On Thursday November 27, 2008 11:07:00 Graham Dumpleton wrote: Why is it dependent on repoze.who? A nicely decoupled system would only need to know that authentication had succeeded which generally is identifiable by REMOTE_USER being set in the WSGI environment dictionary passed from outer middleware, On the one hand, because I wanted to take advantage of the repoze.who system to run certain authorization-related actions during the process of identification (this is, prepare the authorization system). On the other hand, because REMOTE_USER (which isn't set by r.who) is not always enough and also some of the future features will rely on future/existing repoze.who plugins, for example: - I'll write an X.509-based repoze.who identifier which will authenticate the user if she has a valid SSL cert issued by a trusted Certificate Authority; also, there will be a r.who metadata provider which will load the properties of her certificate. Then, with r.what, you'll have X.509-based predicates [1] which will use the data loaded by the MD provider (e.g., The user must work at ABC, The user's certificate must have been signed by our own Certificate Authority). - Likewise, the repoze.who LDAP plugin will also load the attributes of the current user (e.g., Organization Units) and such data may be very useful for authorization through r.what predicates [1] (e.g., Only the Human Resources department can access the payroll). Trying to achieve the above independently of repoze.who will require much too more code/effort for the developer because she will have to (1) take care of the X.509/LDAP authentication (possibly using an authentication framework), (2) extract the attributes required by the predicates she's going to use and (3) pass such data to repoze.what so that the predicates can work. On the contrary, this way everything will work out-of-the-box. Authentication and identification is absolutely independent of authorization, but authorization very often relies on identification. This is why the goal is to leave r.who as an independent authentication/identification-only project, but make an authorization framework based on its powerful and extensible identification system. where outer middleware has performed authentication, or even where it didn't and REMOTE_USER was set by a web server capable of doing authentication itself such as Apache. For example, in such a situation, you'd just need to configure repoze.who with an identifier that takes that value as the userid, which is very trivial and authorization through r.what will work as usual. I would have thought seriously about decoupling it if I knew of any limitation in the authentication and identification systems of r.who, but I can't think of a situation that cannot be even solved by extending it. Cheers! [1] http://static.repoze.org/whatdocs/Manual/Predicates.html -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
On Nov 28, 12:13 am, Dalius Dobravolskas [EMAIL PROTECTED] wrote: Hello, Gustavo, On the other hand, because REMOTE_USER (which isn't set by r.who) is not always enough and also some of the future features will rely on future/existing repoze.who plugins, for example: I agree with that. Even more REMOTE_USER is not enough to distinguish between different authentication methods when multiple methods are used. Does that mean you ignore AUTH_TYPE variable passed in from Apache where Apache module performs the authentication? Graham Because of that I offer to do following in r.who: Set REMOTE_USER as username. Usually all authentication systems provides one or another form of username. Set x-wsgiorg.user_data with data dict (e.g. certificate details, OpenID SREG data and etc.). Name was proposed by Ian Bicking. This way r.who and r.what will be compatible with other authentication and authorization solutions. -- Daliushttp://blog.sandbox.lt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: repoze.what -- Authorization for WSGI applications
On Nov 28, 12:13 am, Dalius Dobravolskas [EMAIL PROTECTED] wrote: Hello, Gustavo, On the other hand, because REMOTE_USER (which isn't set by r.who) is not always enough and also some of the future features will rely on future/existing repoze.who plugins, for example: I agree with that. Even more REMOTE_USER is not enough to distinguish between different authentication methods when multiple methods are used. Does that mean you ignore AUTH_TYPE variable passed in from Apache where Apache module performs the authentication? My authentication middlewares don't set it but thanks for pointing that. I guess I should implement that. I promise to look in it. My authorization (not yet middleware) can't ignore that because it is only helper functions for users to do authorization. -- Dalius http://blog.sandbox.lt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
repoze.what -- Authorization for WSGI applications
Hello, everybody. I'm writing to let you know about the authorization framework I have been working on, repoze.what: http://static.repoze.org/whatdocs/ Some of its features are: * Web framework independent. * Authorization only. It will only do authorization and nothing else. * _Highly_ extensible. * _Fully_ documented. * Your application's `groups` and `permissions` may be stored in an SQLAlchemy managed database, thanks to the SQL plugin (repoze.what.plugins.sql). * The only requirement is that you use the repoze.who authentication framework (which is configured for you by repoze.what). * It's not hard to get started! It's not a stable software yet, but it's just reached its first beta. Cheers! -- Gustavo Narea http://gustavonarea.net/. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ signature.asc Description: This is a digitally signed message part.
