Re: [Acegisecurity-developer] [Fwd: [Fwd: Re: Authentication and authorization status in OGC-compliant OSS GIS software]]
Krystian Nowak wrote: Do you think it is possible to include DACS (http://dacs.dss.ca/) as a authentication adapter (just as it is with Yale's CAS)? There were talks about the future of authorization in OSS GIS GeoServer (http://docs.codehaus.org/display/GEOS/Home) which heavily uses Spring, so it would be natural to use Acegi. On the other hand there is an Open Geospatial Consortium (OGC) standardising organisation for GIS software and one of their implementation for security used in demos is DACS. The problem is that DACS is native application whereas the GeoServer is a Java webapp. Maybe you have some ideas or already have head about works between DACS and Acegi? Do you find it possible to integrate in any scope (just authentication or maybe even more - to simulate DACS-like authorization using Acegi)? Below there is an email on these talks. If it's not clear for you, please, do not hesitate to ask questions to make it more informative. Hi There are no efforts underway to provide a DACS authentication adapter. Nevertheless, Acegi Security is very flexible in what it will accept for authentication. So I see no reason we couldn't use DACS for authentication. The issue touched upon at the bottom of the email is perhaps the most important issue for your project to address, namely which target platform does OSS GIS GeoServer plan on using. As your project is Java-based, it would make some sense to use Acegi Security with perhaps a nice simple out-of-the-box and platform-portable default authentication mechanism such as JDBC or similar. Then also ship a DACS adapter so system evaluators can see that you support the OGC standard. cheers Ben - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] [Fwd: [Fwd: Re: Authentication and authorization status in OGC-compliant OSS GIS software]]
Ben Alex napisał(a): Nevertheless, Acegi Security is very flexible in what it will accept for authentication. I know. And that's why I like to use Acegi in std 3-tier Java apps. But the GeoServer is a little different, so there will be non-standard approach. The issue touched upon at the bottom of the email is perhaps the most important issue for your project to address, namely which target platform does OSS GIS GeoServer plan on using. As your project is Java-based, it would make some sense to use Acegi Security with perhaps a nice simple out-of-the-box and platform-portable default authentication mechanism such as JDBC or similar. Then also ship a DACS adapter so system evaluators can see that you support the OGC standard. Technically, the GeoServer is a Java-based web application based on servlets which can be deployed in any web application container (Tomcat, Jetty, Resin, etc.). I guess that's the answer for the target platform question. In fact the GeoServer is The Open Planning Project's project, but my company is considering whether to extend it with Acegi as auth* component. Thanks for your help! Kind regards, Krystian Nowak PSNC -- Krystian Nowak [EMAIL PROTECTED] === Poznan Supercomputing and Networking Center Poland, 60-814 Poznan, Zwierzyniecka 20 tel. (+48 61) 8582159 fax. (+48 61) 8582151 http://www.man.poznan.pl === - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] [Fwd: [Fwd: Re: Authentication and authorization status in OGC-compliant OSS GIS software]]
Do you think it is possible to include DACS (http://dacs.dss.ca/) as a authentication adapter (just as it is with Yale's CAS)? There were talks about the future of authorization in OSS GIS GeoServer (http://docs.codehaus.org/display/GEOS/Home) which heavily uses Spring, so it would be natural to use Acegi. On the other hand there is an Open Geospatial Consortium (OGC) standardising organisation for GIS software and one of their implementation for security used in demos is DACS. The problem is that DACS is native application whereas the GeoServer is a Java webapp. Maybe you have some ideas or already have head about works between DACS and Acegi? Do you find it possible to integrate in any scope (just authentication or maybe even more - to simulate DACS-like authorization using Acegi)? Below there is an email on these talks. If it's not clear for you, please, do not hesitate to ask questions to make it more informative. Thanks in advance for your help! Kind regards, Krystian Nowak PSNC -- Krystian Nowak [EMAIL PROTECTED] === Poznan Supercomputing and Networking Center Poland, 60-814 Poznan, Zwierzyniecka 20 tel. (+48 61) 8582159 fax. (+48 61) 8582151 http://www.man.poznan.pl === Wiadomość oryginalna Temat: Re: Authentication and authorization status in OGC-compliant OSS GIS software Data: Thu, 18 Jan 2007 10:36:48 -0800 Nadawca: Barry Brachman [EMAIL PROTECTED] Odpowiedź-Do: [EMAIL PROTECTED] Adresat: Krystian Nowak [EMAIL PROTECTED] Kopia: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Hi all -- Some of this thread was forwarded to me. As the principal designer and implementor of DACS, I thought I might be able to comment a little on a few things that caught my attention. Jody Garnett napisa³(a): I know DACS has been used in an OGC context Is it an OGC standard or only at OWS as demo? DACS is not an OGC standard. It was the subject of three OGC initiatives: CIPI 1.1, CIPI 1.2, and OWS-3. That work mainly dealt with understanding and solving authentication and authorization interoperability issues, and some of the results of those projects were integrated with DACS. As far as I know, nothing is currently being done by the OGC with DACS. what is the benifit for ACEGI? Ah it is a spring security system ... I don't know anything about Acegi (http://acegisecurity.org) other than what I have read on their home page, so I really can't comment on it or compare it with DACS. But at first glance it looks to me like it is quite different from DACS in philosophy, implementation, operation, and feature set. So I suspect the two systems might be aimed at different audiences. As for CAS, it is simply an authentication method, and it is one of many methods supported by DACS. Regardless of how authentication is performed, DACS creates a common internal representation (credentials) which is then exported from DACS to a client, and later sent by a client to DACS with its request. In theory at least, DACS does not care how credentials are transmitted - in an HTTP cookie, via an HTTP extension header, within a URL, or as an argument - these are all possibilities. Clients, which can be middleware, can ask DACS to decode or export credentials, so a DACS identity can easily be converted to some other representation, and importation to DACS from other representations is also possible. Middleware can ask DACS to create credentials. The authorization side of DACS is largely separate and independent of the authentication side. You do not have to use DACS authentication in order to use the DACS access control rule-processing engine. I also can't comment on GeoServer. I believe that, like Acegi, it is a Java application, and DACS being C/C++ software, people who prefer a pure Java solution might not be happy with a system that must use JNI. Supporting DACS as an optional, third-party component of GeoServer might be a possibility though. One other thing that I noticed: Do you know if there is any way to integrate Acegi with DACS? I don't really understand this question because the two systems are quite different, yet in broad terms, do the same kinds of things. So I'm not sure what it would mean to integrate Acegi with DACS. It might be possible for Acegi to use DACS's authentication components, its access control component, or both, but that's probably a question to ask the Acegi folks. And there's also that pesky pure Java issue. It might be possible for the two systems to interoperate, but I don't think that's what you're talking about. I apologize if I've gotten off topic or confused things. I'd be happy to answer any questions that anyone has about DACS. Barry ** Barry Brachman, Ph.D. ** Distributed Systems Software, Inc. - Take Surveys. Earn Cash.
Re: [Acegisecurity-developer] [Fwd: [Fwd: Re: Authentication and authorization status in OGC-compliant OSS GIS software]]
If you can find a means to make java code authenticate against DACS, then it would be easy enough to write an Acegi AuthenticationProvider that talks to it. On 1/19/07, Krystian Nowak [EMAIL PROTECTED] wrote: Do you think it is possible to include DACS (http://dacs.dss.ca/) as a authentication adapter (just as it is with Yale's CAS)? There were talks about the future of authorization in OSS GIS GeoServer (http://docs.codehaus.org/display/GEOS/Home) which heavily uses Spring, so it would be natural to use Acegi. On the other hand there is an Open Geospatial Consortium (OGC) standardising organisation for GIS software and one of their implementation for security used in demos is DACS. The problem is that DACS is native application whereas the GeoServer is a Java webapp. Maybe you have some ideas or already have head about works between DACS and Acegi? Do you find it possible to integrate in any scope (just authentication or maybe even more - to simulate DACS-like authorization using Acegi)? Below there is an email on these talks. If it's not clear for you, please, do not hesitate to ask questions to make it more informative. Thanks in advance for your help! Kind regards, Krystian Nowak PSNC -- Krystian Nowak [EMAIL PROTECTED] === Poznan Supercomputing and Networking Center Poland, 60-814 Poznan, Zwierzyniecka 20 tel. (+48 61) 8582159 fax. (+48 61) 8582151 http://www.man.poznan.pl === Wiadomość oryginalna Temat: Re: Authentication and authorization status in OGC-compliant OSS GIS software Data: Thu, 18 Jan 2007 10:36:48 -0800 Nadawca: Barry Brachman [EMAIL PROTECTED] Odpowiedź-Do: [EMAIL PROTECTED] Adresat: Krystian Nowak [EMAIL PROTECTED] Kopia: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Hi all -- Some of this thread was forwarded to me. As the principal designer and implementor of DACS, I thought I might be able to comment a little on a few things that caught my attention. Jody Garnett napisa³(a): I know DACS has been used in an OGC context Is it an OGC standard or only at OWS as demo? DACS is not an OGC standard. It was the subject of three OGC initiatives: CIPI 1.1, CIPI 1.2, and OWS-3. That work mainly dealt with understanding and solving authentication and authorization interoperability issues, and some of the results of those projects were integrated with DACS. As far as I know, nothing is currently being done by the OGC with DACS. what is the benifit for ACEGI? Ah it is a spring security system ... I don't know anything about Acegi (http://acegisecurity.org) other than what I have read on their home page, so I really can't comment on it or compare it with DACS. But at first glance it looks to me like it is quite different from DACS in philosophy, implementation, operation, and feature set. So I suspect the two systems might be aimed at different audiences. As for CAS, it is simply an authentication method, and it is one of many methods supported by DACS. Regardless of how authentication is performed, DACS creates a common internal representation (credentials) which is then exported from DACS to a client, and later sent by a client to DACS with its request. In theory at least, DACS does not care how credentials are transmitted - in an HTTP cookie, via an HTTP extension header, within a URL, or as an argument - these are all possibilities. Clients, which can be middleware, can ask DACS to decode or export credentials, so a DACS identity can easily be converted to some other representation, and importation to DACS from other representations is also possible. Middleware can ask DACS to create credentials. The authorization side of DACS is largely separate and independent of the authentication side. You do not have to use DACS authentication in order to use the DACS access control rule-processing engine. I also can't comment on GeoServer. I believe that, like Acegi, it is a Java application, and DACS being C/C++ software, people who prefer a pure Java solution might not be happy with a system that must use JNI. Supporting DACS as an optional, third-party component of GeoServer might be a possibility though. One other thing that I noticed: Do you know if there is any way to integrate Acegi with DACS? I don't really understand this question because the two systems are quite different, yet in broad terms, do the same kinds of things. So I'm not sure what it would mean to integrate Acegi with DACS. It might be possible for Acegi to use DACS's authentication components, its access control component, or both, but that's probably a question to ask the Acegi folks. And there's also that pesky pure Java issue. It might be possible for the two systems to interoperate, but I don't think that's what you're talking
