16 Sep
2007
16 Sep
'07
2:10 a.m.
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"
18 Sep
18 Sep
9:14 a.m.
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"
12:34 p.m.
New subject: [xwiki-devs] XWiki Identity Management - Integrating Enterprise Sign On Engine
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:
--
Bradley Beddoes
Lead Software Architect
Intient
http://intient.com - "Building intelligent open source solutions for
your enterprise"
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:05 p.m.
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:
--
Bradley Beddoes
Lead Software Architect
Intient
http://intient.com - "Building intelligent open source solutions for
your enterprise"
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Sep
20 Sep
12:11 p.m.
New subject: [xwiki-devs] XWiki Identity Management - Integrating Enterprise Sign On Engine
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"
12:23 p.m.
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:
cool
...
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.
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
12:24 p.m.
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:
cool
...
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.
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
12:41 p.m.
New subject: [xwiki-devs] XWiki Identity Management - Integrating Enterprise Sign On Engine
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:
--
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
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?.
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:
cool
...
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.
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
12:50 p.m.
On Sep 20, 2007, at 12:41 PM, Bradley Beddoes wrote:
Hi,
Vincent Massol wrote:
fair enough.
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.
ok
Thanks
-Vincent
On Sep 20,
2007, at 12:23 PM, Vincent Massol wrote:
--
Bradley Beddoes
Lead Software Architect
Intient
http://intient.com - "Building intelligent open source solutions for
your enterprise"
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Sep 20, 2007, at 12:11 PM, Bradley Beddoes
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
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?.
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
6259
days inactive
6263
days old
8 comments
2 participants
participants (2)
-
Bradley Beddoes -
Vincent Massol