[xwiki-devs] XWiki Identity Management - Integrating Enterprise Sign On Engine
Hi All, We have a project called the Enterprise Sign On Engine ( http://esoeproject.org ) which is an Apache 2.0 licensed platform for authentication, authorization and accountability for both internal enterprise users and federated contexts. About 4 months ago I talked to some of you on this list and there was some interest in integration, we are now in a position to really try and bring this forward. With ESOE integrated into Xwiki you would automatically get the benefits of using openID and Shibboleth. Xwiki would also get our ability to do true single sign on from Active Directory enabled enterprise clients. We also have a very powerful XACML based authorization engine which allows some really unique flexibility in providing access control to content. All said and done we are trying to provide a clean general purpose solution to identity and federation that can be used across many products without needing to continually reimplement this kind of thing. You don't have to write your own database for every application you create we believe it should and can be the same way with identity. We intend to support further technologies in the future such as Yahoo's BBAuth and Microsofts Identity Card. The really neat thing is that the application side doesn't need to be changed at all when these new options come on board for end users. Please take a look around the website and I would really like to talk further with you guys if there is an interest in doing some work together. regards, Bradley -- Bradley Beddoes Lead Software Architect Intient http://intient.com - "Building intelligent open source solutions for your enterprise"
Hi Bradley, I'm definitely +1 for all this below. Let me know how you want to get started. Maybe you could review the existing XWiki authentication/ authorization APIs and see if they are "powerful" enough so that an ESOE bridge can be developed using them? I'm pretty sure we'll find things missing but then we could make a stronger API. Actually since we're talking about XWiki Architecture V2, it might be a good time to review these APIs and propose some better ones, using ESOE as a use case. WDYT? Thanks -Vincent On Sep 16, 2007, at 2:10 AM, Bradley Beddoes wrote:
Hi All,
We have a project called the Enterprise Sign On Engine ( http://esoeproject.org ) which is an Apache 2.0 licensed platform for authentication, authorization and accountability for both internal enterprise users and federated contexts. About 4 months ago I talked to some of you on this list and there was some interest in integration, we are now in a position to really try and bring this forward.
With ESOE integrated into Xwiki you would automatically get the benefits of using openID and Shibboleth. Xwiki would also get our ability to do true single sign on from Active Directory enabled enterprise clients. We also have a very powerful XACML based authorization engine which allows some really unique flexibility in providing access control to content.
All said and done we are trying to provide a clean general purpose solution to identity and federation that can be used across many products without needing to continually reimplement this kind of thing. You don't have to write your own database for every application you create we believe it should and can be the same way with identity.
We intend to support further technologies in the future such as Yahoo's BBAuth and Microsofts Identity Card. The really neat thing is that the application side doesn't need to be changed at all when these new options come on board for end users.
Please take a look around the website and I would really like to talk further with you guys if there is an interest in doing some work together.
regards, Bradley
-- Bradley Beddoes Lead Software Architect Intient
http://intient.com - "Building intelligent open source solutions for your enterprise"
Hi Vincent, I guess some decisions that I would be interested in would be: * Do you consider ESOE to be 'the' solution for XWiki authentication or would you like to offer a mixed mode with say straight LDAP/database as well. * When is V2 starting development or due to be shipped? It might be worthwhile simply targeting that version. * Are you guys currently using Acegi or are you likely to use that or something similar for v2? Please excuse my ignorance but where might I find the v2 documentation. regards, Bradley Vincent Massol wrote:
Hi Bradley,
I'm definitely +1 for all this below.
Let me know how you want to get started.
Maybe you could review the existing XWiki authentication/ authorization APIs and see if they are "powerful" enough so that an ESOE bridge can be developed using them? I'm pretty sure we'll find things missing but then we could make a stronger API. Actually since we're talking about XWiki Architecture V2, it might be a good time to review these APIs and propose some better ones, using ESOE as a use case.
WDYT?
Thanks -Vincent
On Sep 16, 2007, at 2:10 AM, Bradley Beddoes wrote:
Hi All,
We have a project called the Enterprise Sign On Engine ( http://esoeproject.org ) which is an Apache 2.0 licensed platform for authentication, authorization and accountability for both internal enterprise users and federated contexts. About 4 months ago I talked to some of you on this list and there was some interest in integration, we are now in a position to really try and bring this forward.
With ESOE integrated into Xwiki you would automatically get the benefits of using openID and Shibboleth. Xwiki would also get our ability to do true single sign on from Active Directory enabled enterprise clients. We also have a very powerful XACML based authorization engine which allows some really unique flexibility in providing access control to content.
All said and done we are trying to provide a clean general purpose solution to identity and federation that can be used across many products without needing to continually reimplement this kind of thing. You don't have to write your own database for every application you create we believe it should and can be the same way with identity.
We intend to support further technologies in the future such as Yahoo's BBAuth and Microsofts Identity Card. The really neat thing is that the application side doesn't need to be changed at all when these new options come on board for end users.
Please take a look around the website and I would really like to talk further with you guys if there is an interest in doing some work together.
regards, Bradley
-- Bradley Beddoes Lead Software Architect Intient
http://intient.com - "Building intelligent open source solutions for your enterprise"
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Bradley Beddoes Lead Software Architect Intient http://intient.com - "Building intelligent open source solutions for your enterprise"
On Sep 18, 2007, at 12:34 PM, Bradley Beddoes wrote:
Hi Vincent, I guess some decisions that I would be interested in would be:
* Do you consider ESOE to be 'the' solution for XWiki authentication or would you like to offer a mixed mode with say straight LDAP/ database as well.
We need XWiki Interfaces and then we can plug several implementations, one of them being ESOE (at least that's my POV and my preference if possible). We do the same with all frameworks we use (hibernate for the storage, rendering, etc).
* When is V2 starting development or due to be shipped? It might be worthwhile simply targeting that version.
V2 is a meme. It's something amorphous. It has started already. It's about slowly replacing XWiki current code with components. Some will be in 1.2, more will be in 1.3, etc. At the same time as we're doing components, we're also revisiting interfaces.
* Are you guys currently using Acegi or are you likely to use that or something similar for v2?
We're not using it. We haven't decided what we do. Is ESOE a superset of Acegi, are they competitors, etc. Do you know JGuard? Is it a competitor to ESOE or are they in different domains? As you can see this is not a domain I know well so if you're interested in bringing your expertise to XWiki then that would be cool :)
Please excuse my ignorance but where might I find the v2 documentation.
Some threads/links on component development: http://www.nabble.com/-XWiki-V2--Componentizing-XWiki-with-Plexus- tf4226730.html#a12024444 http://www.xwiki.org/xwiki/bin/view/Design/ArchitectureV2 Thanks -Vincent
Vincent Massol wrote:
Hi Bradley,
I'm definitely +1 for all this below.
Let me know how you want to get started.
Maybe you could review the existing XWiki authentication/ authorization APIs and see if they are "powerful" enough so that an ESOE bridge can be developed using them? I'm pretty sure we'll find things missing but then we could make a stronger API. Actually since we're talking about XWiki Architecture V2, it might be a good time to review these APIs and propose some better ones, using ESOE as a use case.
WDYT?
Thanks -Vincent
On Sep 16, 2007, at 2:10 AM, Bradley Beddoes wrote:
Hi All,
We have a project called the Enterprise Sign On Engine ( http://esoeproject.org ) which is an Apache 2.0 licensed platform for authentication, authorization and accountability for both internal enterprise users and federated contexts. About 4 months ago I talked to some of you on this list and there was some interest in integration, we are now in a position to really try and bring this forward.
With ESOE integrated into Xwiki you would automatically get the benefits of using openID and Shibboleth. Xwiki would also get our ability to do true single sign on from Active Directory enabled enterprise clients. We also have a very powerful XACML based authorization engine which allows some really unique flexibility in providing access control to content.
All said and done we are trying to provide a clean general purpose solution to identity and federation that can be used across many products without needing to continually reimplement this kind of thing. You don't have to write your own database for every application you create we believe it should and can be the same way with identity.
We intend to support further technologies in the future such as Yahoo's BBAuth and Microsofts Identity Card. The really neat thing is that the application side doesn't need to be changed at all when these new options come on board for end users.
Please take a look around the website and I would really like to talk further with you guys if there is an interest in doing some work together.
regards, Bradley
-- Bradley Beddoes Lead Software Architect Intient
http://intient.com - "Building intelligent open source solutions for your enterprise"
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Bradley Beddoes Lead Software Architect Intient
http://intient.com - "Building intelligent open source solutions for your enterprise" _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Vincent, So I have had a look at the links provided below and while I don't know the Plexus framework very well I understand what its purpose is. Not to interfere in architecture decisions but Spring OSGi also looks quite nice in this space. Is Xwiki built around Spring?. Vincent Massol wrote:
...
We're not using it. We haven't decided what we do. Is ESOE a superset of Acegi, are they competitors, etc. Do you know JGuard? Is it a competitor to ESOE or are they in different domains? As you can see this is not a domain I know well so if you're interested in bringing your expertise to XWiki then that would be cool :)
I think Acegi is going to play very nicely with what you guys are trying to do. I am going to embark on an Acegi -> ESOE integration over the next week or so which will mean that anything using Acegi will be right to go with ESOE. What Acegi will give you is really nice pluggable authentication, authorization and User management which will mean users wanting to do enterprise level SSO and authorization with ESOE will be able to do that but those wishing to just auth against ldap will also be able to do that. So Acegi is basically an integrator at the application level. ESOE and its associated client side SPEP is a step above that, it does all the heavy SAML and XACML lifting, the SPEP will hook into Acegi (just like say LDAP could) and provide the source of authentication, identity and authorization that Acegi will rely on when the application calls it. From the limited look I have had at JGuard it seems to play in the same space as Acegi. Hope this is of some help let me know what you think about Acegi, if you want to go with designing your own layer I'd need to probably see some discussion around that so I can give you feedback. regards, Bradley -- Bradley Beddoes Lead Software Architect Intient http://intient.com - "Building intelligent open source solutions for your enterprise"
On Sep 20, 2007, at 12:11 PM, Bradley Beddoes wrote:
Hi Vincent,
So I have had a look at the links provided below and while I don't know the Plexus framework very well I understand what its purpose is.
Not to interfere in architecture decisions but Spring OSGi also looks quite nice in this space. Is Xwiki built around Spring?.
No it's not built around Spring. The component manager used doesn't matter as this stage. What matters is to have components and a component architecture, components being plain POJOs. This is where our effort is. The first implementation I've done is with Plexus which is hidden away in a single location (in the xwiki-plexus/ build module) and there isn't a single import of Plexus in any other place.
Vincent Massol wrote:
...
We're not using it. We haven't decided what we do. Is ESOE a superset of Acegi, are they competitors, etc. Do you know JGuard? Is it a competitor to ESOE or are they in different domains? As you can see this is not a domain I know well so if you're interested in bringing your expertise to XWiki then that would be cool :)
I think Acegi is going to play very nicely with what you guys are trying to do. I am going to embark on an Acegi -> ESOE integration over the next week or so which will mean that anything using Acegi will be right to go with ESOE.
What Acegi will give you is really nice pluggable authentication, authorization and User management which will mean users wanting to do enterprise level SSO and authorization with ESOE will be able to do that but those wishing to just auth against ldap will also be able to do that.
cool
So Acegi is basically an integrator at the application level. ESOE and its associated client side SPEP is a step above that, it does all the heavy SAML and XACML lifting, the SPEP will hook into Acegi (just like say LDAP could) and provide the source of authentication, identity and authorization that Acegi will rely on when the application calls it.
ok, I understand. Sounds good then.
From the limited look I have had at JGuard it seems to play in the same space as Acegi.
Hope this is of some help let me know what you think about Acegi, if you want to go with designing your own layer I'd need to probably see some discussion around that so I can give you feedback.
We only want to have our own interfaces (as in Java Interfaces). The implementation can be using Acegi and ESOE. Unfortunately nobody here is currently working on these interfaces right now. In term of architecture improvements, the work in progress currently are: * New Rendering/Parsing interfaces using WikiModel - Vincent (me) * Velocity component - Vincent (me) * New Notification/Observation component - Vincent (me) * New Action component - Vincent (me) * New URL management component - Vincent (me) * New WYSIWYG editor architecture based on GWT and WikiModel - Marius * New Rights Management UI - Thomas M You can see a summary of these and more on the design space of xwiki.org (not yet fully up to date though): * old location: http://www.xwiki.org/xwiki/bin/view/Idea/ (there are still some proposals not moved to the new Design space in there which is why I'm listing it here) * new location: http://www.xwiki.org/xwiki/bin/view/Design/ Thanks -Vincent
Forgot to state the obvious: If you're interested in help us shape the XWiki security APIs you're more than welcome :) Thanks -Vincent On Sep 20, 2007, at 12:23 PM, Vincent Massol wrote:
On Sep 20, 2007, at 12:11 PM, Bradley Beddoes wrote:
Hi Vincent,
So I have had a look at the links provided below and while I don't know the Plexus framework very well I understand what its purpose is.
Not to interfere in architecture decisions but Spring OSGi also looks quite nice in this space. Is Xwiki built around Spring?.
No it's not built around Spring.
The component manager used doesn't matter as this stage. What matters is to have components and a component architecture, components being plain POJOs. This is where our effort is. The first implementation I've done is with Plexus which is hidden away in a single location (in the xwiki-plexus/ build module) and there isn't a single import of Plexus in any other place.
Vincent Massol wrote:
...
We're not using it. We haven't decided what we do. Is ESOE a superset of Acegi, are they competitors, etc. Do you know JGuard? Is it a competitor to ESOE or are they in different domains? As you can see this is not a domain I know well so if you're interested in bringing your expertise to XWiki then that would be cool :)
I think Acegi is going to play very nicely with what you guys are trying to do. I am going to embark on an Acegi -> ESOE integration over the next week or so which will mean that anything using Acegi will be right to go with ESOE.
What Acegi will give you is really nice pluggable authentication, authorization and User management which will mean users wanting to do enterprise level SSO and authorization with ESOE will be able to do that but those wishing to just auth against ldap will also be able to do that.
cool
So Acegi is basically an integrator at the application level. ESOE and its associated client side SPEP is a step above that, it does all the heavy SAML and XACML lifting, the SPEP will hook into Acegi (just like say LDAP could) and provide the source of authentication, identity and authorization that Acegi will rely on when the application calls it.
ok, I understand. Sounds good then.
From the limited look I have had at JGuard it seems to play in the same space as Acegi.
Hope this is of some help let me know what you think about Acegi, if you want to go with designing your own layer I'd need to probably see some discussion around that so I can give you feedback.
We only want to have our own interfaces (as in Java Interfaces). The implementation can be using Acegi and ESOE.
Unfortunately nobody here is currently working on these interfaces right now. In term of architecture improvements, the work in progress currently are:
* New Rendering/Parsing interfaces using WikiModel - Vincent (me) * Velocity component - Vincent (me) * New Notification/Observation component - Vincent (me) * New Action component - Vincent (me) * New URL management component - Vincent (me) * New WYSIWYG editor architecture based on GWT and WikiModel - Marius * New Rights Management UI - Thomas M
You can see a summary of these and more on the design space of xwiki.org (not yet fully up to date though): * old location: http://www.xwiki.org/xwiki/bin/view/Idea/ (there are still some proposals not moved to the new Design space in there which is why I'm listing it here) * new location: http://www.xwiki.org/xwiki/bin/view/Design/
Thanks -Vincent
Hi, Vincent Massol wrote:
Forgot to state the obvious:
If you're interested in help us shape the XWiki security APIs you're more than welcome :)
To be completely honest right at the moment I am so over committed on various things not to mention trying to run a new company and assist clients to that one day I might be able to eat again I really can't commit to this. I will however keep an eye on the list and happy to contribute if others want to discuss and take a lead. If I get time i the future I may be able to offer more. Bradley
Thanks -Vincent
On Sep 20, 2007, at 12:23 PM, Vincent Massol wrote:
On Sep 20, 2007, at 12:11 PM, Bradley Beddoes wrote:
Hi Vincent,
So I have had a look at the links provided below and while I don't know the Plexus framework very well I understand what its purpose is.
Not to interfere in architecture decisions but Spring OSGi also looks quite nice in this space. Is Xwiki built around Spring?. No it's not built around Spring.
The component manager used doesn't matter as this stage. What matters is to have components and a component architecture, components being plain POJOs. This is where our effort is. The first implementation I've done is with Plexus which is hidden away in a single location (in the xwiki-plexus/ build module) and there isn't a single import of Plexus in any other place.
Vincent Massol wrote:
...
We're not using it. We haven't decided what we do. Is ESOE a superset of Acegi, are they competitors, etc. Do you know JGuard? Is it a competitor to ESOE or are they in different domains? As you can see this is not a domain I know well so if you're interested in bringing your expertise to XWiki then that would be cool :) I think Acegi is going to play very nicely with what you guys are trying to do. I am going to embark on an Acegi -> ESOE integration over the next week or so which will mean that anything using Acegi will be right to go with ESOE.
What Acegi will give you is really nice pluggable authentication, authorization and User management which will mean users wanting to do enterprise level SSO and authorization with ESOE will be able to do that but those wishing to just auth against ldap will also be able to do that. cool
So Acegi is basically an integrator at the application level. ESOE and its associated client side SPEP is a step above that, it does all the heavy SAML and XACML lifting, the SPEP will hook into Acegi (just like say LDAP could) and provide the source of authentication, identity and authorization that Acegi will rely on when the application calls it. ok, I understand. Sounds good then.
From the limited look I have had at JGuard it seems to play in the same space as Acegi.
Hope this is of some help let me know what you think about Acegi, if you want to go with designing your own layer I'd need to probably see some discussion around that so I can give you feedback. We only want to have our own interfaces (as in Java Interfaces). The implementation can be using Acegi and ESOE.
Unfortunately nobody here is currently working on these interfaces right now. In term of architecture improvements, the work in progress currently are:
* New Rendering/Parsing interfaces using WikiModel - Vincent (me) * Velocity component - Vincent (me) * New Notification/Observation component - Vincent (me) * New Action component - Vincent (me) * New URL management component - Vincent (me) * New WYSIWYG editor architecture based on GWT and WikiModel - Marius * New Rights Management UI - Thomas M
You can see a summary of these and more on the design space of xwiki.org (not yet fully up to date though): * old location: http://www.xwiki.org/xwiki/bin/view/Idea/ (there are still some proposals not moved to the new Design space in there which is why I'm listing it here) * new location: http://www.xwiki.org/xwiki/bin/view/Design/
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Bradley Beddoes Lead Software Architect Intient http://intient.com - "Building intelligent open source solutions for your enterprise"
On Sep 20, 2007, at 12:41 PM, Bradley Beddoes wrote:
Hi, Vincent Massol wrote:
Forgot to state the obvious:
If you're interested in help us shape the XWiki security APIs you're more than welcome :)
To be completely honest right at the moment I am so over committed on various things not to mention trying to run a new company and assist clients to that one day I might be able to eat again I really can't commit to this.
fair enough.
I will however keep an eye on the list and happy to contribute if others want to discuss and take a lead. If I get time i the future I may be able to offer more.
ok Thanks -Vincent
On Sep 20, 2007, at 12:23 PM, Vincent Massol wrote:
On Sep 20, 2007, at 12:11 PM, Bradley Beddoes wrote:
Hi Vincent,
So I have had a look at the links provided below and while I don't know the Plexus framework very well I understand what its purpose is.
Not to interfere in architecture decisions but Spring OSGi also looks quite nice in this space. Is Xwiki built around Spring?. No it's not built around Spring.
The component manager used doesn't matter as this stage. What matters is to have components and a component architecture, components being plain POJOs. This is where our effort is. The first implementation I've done is with Plexus which is hidden away in a single location (in the xwiki-plexus/ build module) and there isn't a single import of Plexus in any other place.
Vincent Massol wrote:
...
We're not using it. We haven't decided what we do. Is ESOE a superset of Acegi, are they competitors, etc. Do you know JGuard? Is it a competitor to ESOE or are they in different domains? As you can see this is not a domain I know well so if you're interested in bringing your expertise to XWiki then that would be cool :) I think Acegi is going to play very nicely with what you guys are trying to do. I am going to embark on an Acegi -> ESOE integration over the next week or so which will mean that anything using Acegi will be right to go with ESOE.
What Acegi will give you is really nice pluggable authentication, authorization and User management which will mean users wanting to do enterprise level SSO and authorization with ESOE will be able to do that but those wishing to just auth against ldap will also be able to do that. cool
So Acegi is basically an integrator at the application level. ESOE and its associated client side SPEP is a step above that, it does all the heavy SAML and XACML lifting, the SPEP will hook into Acegi (just like say LDAP could) and provide the source of authentication, identity and authorization that Acegi will rely on when the application calls it. ok, I understand. Sounds good then.
From the limited look I have had at JGuard it seems to play in the same space as Acegi.
Hope this is of some help let me know what you think about Acegi, if you want to go with designing your own layer I'd need to probably see some discussion around that so I can give you feedback. We only want to have our own interfaces (as in Java Interfaces). The implementation can be using Acegi and ESOE.
Unfortunately nobody here is currently working on these interfaces right now. In term of architecture improvements, the work in progress currently are:
* New Rendering/Parsing interfaces using WikiModel - Vincent (me) * Velocity component - Vincent (me) * New Notification/Observation component - Vincent (me) * New Action component - Vincent (me) * New URL management component - Vincent (me) * New WYSIWYG editor architecture based on GWT and WikiModel - Marius * New Rights Management UI - Thomas M
You can see a summary of these and more on the design space of xwiki.org (not yet fully up to date though): * old location: http://www.xwiki.org/xwiki/bin/view/Idea/ (there are still some proposals not moved to the new Design space in there which is why I'm listing it here) * new location: http://www.xwiki.org/xwiki/bin/view/Design/
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Bradley Beddoes Lead Software Architect Intient
http://intient.com - "Building intelligent open source solutions for your enterprise" _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Bradley Beddoes -
Vincent Massol