[prev in list] [next in list] [prev in thread] [next in thread]
List: forgerock-openig-dev
Subject: Re: [Openig-dev] Some proposals for OpenIG
From: Mark de Reeper <mark.dereeper () forgerock ! com>
Date: 2014-04-11 23:44:45
Message-ID: CAGrS82KaY9-kac0Di=w4Bt_9veATBA4ivjZKRXMaEj51yOTrKQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Matt,
On 12 April 2014 00:13, Matthew Swift <matthew.swift@forgerock.com> wrote:
> Hi folks,
>
> [Warren - I've CC'd you in for your opinions. I suggest joining the
> openig-dev mailing list if possible]
>
> Now that I'm becoming more familiar with OpenIG, I would like to propose
> some changes and I would like your feedback. Please, please, please let me
> know ASAP if you disagree with any of them, or if you have better
> suggestions. Here they are:
>
Why the rush?
>
> 1. Remove the openig-saas/pbworks module. Is anyone using it? Is it
> maintained?
>
> Never seen anyone use this, never touched it. Jamie will know more about
the history.
>
> 1. Combine the remaining three modules into a single OpenIG
> application WAR. Remember that one of our goals is to have a single
> standalone executable, so this seems like a natural step towards that goal.
>
> Seems reasonable as long as when not using one of the other X modules they
are not being triggered/loaded unless specifically enabled.
>
> 1. Leading on from (2) above, deliver OpenIG as a single application
> and/or WAR containing the SAML support, OAuth support, and the OpenAM
> policy agent bundled together. User then selects which form of protection
> they want to use when configuring OpenIG. Questions:
>
> 1. Is it reasonable to include an OpenAM policy agent out of the box?
> Will it bloat OpenIG too much?
>
> Worked well in my prototype of an all-in-one IG/Agent/container, main
issue will be which agent to include since there are subtle differences
between the container you are going to run it in. If done as part of
combined container product where we control which container then should
work well. The agent can easily be disabled if not required during runtime
by not including the agent filter and not deploying the agent callback
webapp. Apart from the container issue, next key problem will be providing
an appropriate bootstrap config for the agent but if we are also going to
be providing a configuration cli/GUI then this can be taken care of during
that process.
>
> 1. What are the requirements regarding service protection? Will the
> same form of protection (e.g. SAML) be used for all services exposed by an
> OpenIG instance? Or do we expect more heterogeneous deployments where
> different services are protected in different ways, e.g. service A using
> SAML, service B using SAML configured differently to service A, service C
> using OAuth, etc?
>
> I see plenty of use-cases for multiple applications behind an instance of
OpenIG but extending that to provide different authentication methods
depending on the app may not be so important and would be challenging to
provide. The concept of multiple SAML configurations is more likely but
problematic based on the current Fedlet implementation and may require some
upstream changes for it to be supported in OpenIG.
>
> 1. Drop support for integration with third-party J2EE \
> Servlets<http://docs.forgerock.org/en/openig/2.1.0/reference/index.html#Servlet>and \
> Servlet Filters<http://docs.forgerock.org/en/openig/2.1.0/reference/index.html#ServletFilter>.
> I think that these are only required for integration with our various
> protection layers (e.g. SAML Servlet), but I think that this is an
> implementation detail which should not be exposed to users as it
> complicates the configuration model, e.g. as a user wishing to extend
> OpenIG do I implement a Servlet Filter or an OpenIG Filter? Note that the
> Servlet Filter support in OpenIG doesn't actually work today so I don't
> think anyone is using it :-)
>
> +1
>
> 1. Consider supporting CORS out of the box. Note that containers like
> Jetty already have such support and it is exposed as a Servlet Filter, see
> (4) above.
>
> Not sure since I haven't done enough reading on the subject but if it
means another tick on a marketing flyer and it providing it is not going to
break things then +1
>
> 1. Consider having a global option to configure the default scripting
> engine. Once we add scripting support, e.g. for Groovy, it seems a little
> strange to configure conditions, etc using JUEL expressions and scriptable
> filters/handlers using Groovy. As a user I would like to be able to use my
> scripting language of choice everywhere and not have to understand more
> than one language in order to use OpenIG.
>
> I think that as long at is was configurable then fine but the current
mechanism whilst not great does provide reasonable solutions to most
use-cases without the user having to be a programmer as such. I don't think
that it should be an either/or thing, using Expressions and providing the
ability to extend the config using scripting (Groovy) will be a useful
thing.
As an aside, what if any is the performance impact of calling out to a
scripting engine like Groovy?
>
> 1. Change the default configuration location. At the moment the
> configuration is stored in $HOME/.ForgeRock/OpenIG/config.json which seems
> a bit unconventional. I suggest two locations:
>
> - When deployed in a container as a webapp:
> $HOME/.openig/config/config.json. Scripts in $HOME/.openig/scripts/<lang>.
>
> Current way has the same problem, what happens when there are multiple
containers using two different OpenIG deployments on the same user/host
(very common in dev systems)?
The OpenAM approach is to use the container location as a file name under
$HOME/.openam which contains a single entry which is the path to the actual
config location. The current OpenIG impl has something like this already
and kicks in if it cannot find the default config file.
>
> - When deployed as a standalone app: $INSTALL/config/config.json.
> Scripts in $INSTALL/scripts/<lang>.
>
> +1
> Please note that these suggestions are in addition to those that we
> already know about and have agreed upon. In particular: Oauth support,
> standalone mode, automatic reloading of scripts, simplified configuration
> (split config - one file per service).
>
>
+1
> Let me know what you think and, if no one disagrees, I'll go ahead and add
> these to JIRA.
>
> Matt
>
Thanks
Mark
[Attachment #5 (text/html)]
<div dir="ltr">Hi Matt,<div><br></div><div><br></div><div class="gmail_extra"><div \
class="gmail_quote">On 12 April 2014 00:13, Matthew Swift <span dir="ltr"><<a \
href="mailto:matthew.swift@forgerock.com" \
target="_blank">matthew.swift@forgerock.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">Hi folks,<div><br></div><div>[Warren - \
I've CC'd you in for your opinions. I suggest joining the openig-dev mailing \
list if possible]</div> <div><br></div><div>Now that I'm becoming more familiar \
with OpenIG, I would like to propose some changes and I would like your feedback. \
Please, please, please let me know ASAP if you disagree with any of them, or if you \
have better suggestions. Here they are:</div> \
</div></blockquote><div><br></div><div>Why the rush? </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"> <div><ol><li>Remove the openig-saas/pbworks \
module. Is anyone using it? Is it \
maintained?<br></li></ol></div></div></blockquote><div>Never seen anyone use this, \
never touched it. Jamie will know more about the history. </div> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><ol><li>Combine the remaining three \
modules into a single OpenIG application WAR. Remember that one of our goals is to \
have a single standalone executable, so this seems like a natural step towards that \
goal.<br> </li></ol></div></div></blockquote><div>Seems reasonable as long as when \
not using one of the other X modules they are not being triggered/loaded unless \
specifically enabled.</div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div \
dir="ltr"><div><ol><li>Leading on from (2) above, deliver OpenIG as a single \
application and/or WAR containing the SAML support, OAuth support, and the OpenAM \
policy agent bundled together. User then selects which form of protection they want \
to use when configuring OpenIG. Questions:<br>
<br></li><ol><li>Is it reasonable to include an OpenAM policy agent out of the box? \
Will it bloat OpenIG too much?<br></li></ol></ol></div></div></blockquote><div>Worked \
well in my prototype of an all-in-one IG/Agent/container, main issue will be which \
agent to include since there are subtle differences between the container you are \
going to run it in. If done as part of combined container product where we control \
which container then should work well. The agent can easily be disabled if not \
required during runtime by not including the agent filter and not deploying the agent \
callback webapp. Apart from the container issue, next key problem will be providing \
an appropriate bootstrap config for the agent but if we are also going to be \
providing a configuration cli/GUI then this can be taken care of during that \
process.</div> <blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr"><div><ol><ol><li>What are the requirements regarding service protection? \
Will the same form of protection (e.g. SAML) be used for all services exposed by an \
OpenIG instance? Or do we expect more heterogeneous deployments where different \
services are protected in different ways, e.g. service A using SAML, service B using \
SAML configured differently to service A, service C using OAuth, etc?<br> \
</li></ol></ol></div></div></blockquote><div>I see plenty of use-cases for multiple \
applications behind an instance of OpenIG but extending that to provide different \
authentication methods depending on the app may not be so important and would be \
challenging to provide. The concept of multiple SAML configurations is more likely \
but problematic based on the current Fedlet implementation and may require some \
upstream changes for it to be supported in OpenIG.</div> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><ol><li>Drop support for integration with \
third-party <a href="http://docs.forgerock.org/en/openig/2.1.0/reference/index.html#Servlet" \
target="_blank">J2EE Servlets</a> and <a \
href="http://docs.forgerock.org/en/openig/2.1.0/reference/index.html#ServletFilter" \
target="_blank">Servlet Filters</a>. I think that these are only required for \
integration with our various protection layers (e.g. SAML Servlet), but I think that \
this is an implementation detail which should not be exposed to users as it \
complicates the configuration model, e.g. as a user wishing to extend OpenIG do I \
implement a Servlet Filter or an OpenIG Filter? Note that the Servlet Filter support \
in OpenIG doesn't actually work today so I don't think anyone is using it \
:-)<br> </li></ol></div></div></blockquote><div>+1 </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><ol><li>Consider supporting CORS out of \
the box. Note that containers like Jetty already have such support and it is exposed \
as a Servlet Filter, see (4) above.<br> </li></ol></div></div></blockquote><div>Not \
sure since I haven't done enough reading on the subject but if it means another \
tick on a marketing flyer and it providing it is not going to break things then +1 \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div dir="ltr"><div><ol><li>Consider having a global option \
to configure the default scripting engine. Once we add scripting support, e.g. for \
Groovy, it seems a little strange to configure conditions, etc using JUEL expressions \
and scriptable filters/handlers using Groovy. As a user I would like to be able to \
use my scripting language of choice everywhere and not have to understand more than \
one language in order to use OpenIG.<br> </li></ol></div></div></blockquote><div>I \
think that as long at is was configurable then fine but the current mechanism whilst \
not great does provide reasonable solutions to most use-cases without the user having \
to be a programmer as such. I don't think that it should be an either/or thing, \
using Expressions and providing the ability to extend the config using scripting \
(Groovy) will be a useful thing.</div> <div>As an aside, what if any is the \
performance impact of calling out to a scripting engine like Groovy?</div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"> <div><ol><li>Change the default configuration \
location. At the moment the configuration is stored in \
$HOME/.ForgeRock/OpenIG/config.json which seems a bit unconventional. I suggest two \
locations:<br><br></li><ul><li>When deployed in a container as a webapp: \
$HOME/.openig/config/config.json. Scripts in $HOME/.openig/scripts/<lang>.<br> \
</li></ul></ol></div></div></blockquote><div>Current way has the same problem, what \
happens when there are multiple containers using two different OpenIG deployments on \
the same user/host (very common in dev systems)?</div> <div>The OpenAM approach is to \
use the container location as a file name under $HOME/.openam which contains a single \
entry which is the path to the actual config location. The current OpenIG impl has \
something like this already and kicks in if it cannot find the default config \
file.</div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><ul><li>When deployed as a \
standalone app: $INSTALL/config/config.json. Scripts in \
$INSTALL/scripts/<lang>. </li> \
</ul></ol></div></div></blockquote><div>+1</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><div>Please note that these suggestions \
are in addition to those that we already know about and have agreed upon. In \
particular: Oauth support, standalone mode, automatic reloading of scripts, \
simplified configuration (split config - one file per service).</div>
</div><div><br></div></div></blockquote><div> </div><div>+1 </div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div>Let me know what you think and, if no one \
disagrees, I'll go ahead and add these to JIRA.</div> \
<div><br></div><div>Matt</div></div></blockquote><div> \
<br></div><div><br></div><div>Thanks</div><div><br></div><div>Mark \
</div></div><br></div></div>
_______________________________________________
Openig-dev mailing list
Openig-dev@forgerock.org
https://lists.forgerock.org/mailman/listinfo/openig-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic