Security Module

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Security Module

Darran Lofthouse
Just been having a look at the Security Module page and had a couple of
comments related to experiences in JBoss AS - Pete suggested I post my
comments over here.

A few of problems we have had historically in JBoss AS releases
regarding the authentication at the transport level are: -
- The assumption that everything has a username and a credential.
- That authentication takes a single step.
- That the duration an authentication is valid for can be pre-defined.

Looking at the initial API I just wonder is it also starting to follow
the same assumptions.  Picking username / password authentication as a
first step whilst it may be simple historically has led us into
situations where adding more complex scenarios end up being added as a
workaround.

I suppose the real question is where would this be used, is this
something that would only be used within apps that want to establish
some form of 'security context' with an identity or could this also be
used in other locations such as valves implementing http authentication.
  If the former than maybe not a huge issue but if the latter this API
could be repeating the problems of the past.

Regards,
Darran Lofthouse.

Reply | Threaded
Open this post in threaded view
|

Re: Security Module

Jason Porter
Thanks for bringing things up Darran. Take a look at
https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts.
If there's something missing in the use cases, please add some. Also note
we've only gone as far as Part 1 right now. We're going to be continuing
discussions and implementing the other stages as we continue.

On Thu, Apr 12, 2012 at 10:51, Darran Lofthouse <[hidden email]
> wrote:

> Just been having a look at the Security Module page and had a couple of
> comments related to experiences in JBoss AS - Pete suggested I post my
> comments over here.
>
> A few of problems we have had historically in JBoss AS releases regarding
> the authentication at the transport level are: -
> - The assumption that everything has a username and a credential.
> - That authentication takes a single step.
> - That the duration an authentication is valid for can be pre-defined.
>
> Looking at the initial API I just wonder is it also starting to follow the
> same assumptions.  Picking username / password authentication as a first
> step whilst it may be simple historically has led us into situations where
> adding more complex scenarios end up being added as a workaround.
>
> I suppose the real question is where would this be used, is this something
> that would only be used within apps that want to establish some form of
> 'security context' with an identity or could this also be used in other
> locations such as valves implementing http authentication.  If the former
> than maybe not a huge issue but if the latter this API could be repeating
> the problems of the past.
>
> Regards,
> Darran Lofthouse.
>
>


--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Reply | Threaded
Open this post in threaded view
|

Re: Security Module

Mehdi Heidarzadeh
Hi Darran.
If you have any scenario or method of authentication that is not covered in
the link Jason mentioned, then share it here and we will talk about it.

On Thu, Apr 12, 2012 at 9:50 PM, Jason Porter <[hidden email]>wrote:

> Thanks for bringing things up Darran. Take a look at
>
> https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts
> .
> If there's something missing in the use cases, please add some. Also note
> we've only gone as far as Part 1 right now. We're going to be continuing
> discussions and implementing the other stages as we continue.
>
> On Thu, Apr 12, 2012 at 10:51, Darran Lofthouse <
> [hidden email]
> > wrote:
>
> > Just been having a look at the Security Module page and had a couple of
> > comments related to experiences in JBoss AS - Pete suggested I post my
> > comments over here.
> >
> > A few of problems we have had historically in JBoss AS releases regarding
> > the authentication at the transport level are: -
> > - The assumption that everything has a username and a credential.
> > - That authentication takes a single step.
> > - That the duration an authentication is valid for can be pre-defined.
> >
> > Looking at the initial API I just wonder is it also starting to follow
> the
> > same assumptions.  Picking username / password authentication as a first
> > step whilst it may be simple historically has led us into situations
> where
> > adding more complex scenarios end up being added as a workaround.
> >
> > I suppose the real question is where would this be used, is this
> something
> > that would only be used within apps that want to establish some form of
> > 'security context' with an identity or could this also be used in other
> > locations such as valves implementing http authentication.  If the former
> > than maybe not a huge issue but if the latter this API could be repeating
> > the problems of the past.
> >
> > Regards,
> > Darran Lofthouse.
> >
> >
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>



--
Mehdi Heidarzadeh Ardalani
Independent JEE Consultant, Architect and
Developer.<http://www.TheBigJavaBlog.com>
Reply | Threaded
Open this post in threaded view
|

Re: Security Module

Marek Posolda
In reply to this post by Darran Lofthouse
On 12.4.2012 18:51, Darran Lofthouse wrote:
> Just been having a look at the Security Module page and had a couple
> of comments related to experiences in JBoss AS - Pete suggested I post
> my comments over here.
>
> A few of problems we have had historically in JBoss AS releases
> regarding the authentication at the transport level are: -
> - The assumption that everything has a username and a credential.
> - That authentication takes a single step.
> - That the duration an authentication is valid for can be pre-defined.
+1

What I was thinking about, is to have object AuthenticationContext,
which will encapsulate whole state of current user authentication
including credentials, tokens and other things (Username, password,
value of RememberMe cookie, SSO tokens, initialURI to redirect after
authentication...). Point of this object is to wrap all authentication
related data like credentials, urls, tokens etc. and store them between
various HTTP redirects, which are usually needed for some kinds of
authentication.

Second thing may be to have something like set of authentication
interceptors, where each interceptor can be used to deal with some
aspect of authentication. API can look like this


public interface AuthenticationInterceptor
{
   public void invoke(HttpServletRequest request, HttpServletResponse
response, AuthenticationContext context);
}

Examples of interceptors:

     - RememberMeInterceptor to deal with RememberMe cookie,
     - UsernamePasswordInterceptor, which will redirect user to login
screen if his credentials are not already found in AuthenticationContext
(classic username/password usecase)
     - OpenSSOInterceptor, which will redirect user to OpenSSO (or other
SSO server) if OpenSSO ticket not found, or it will perform validation
of SSO ticket if OpenSSO ticket is found

These interceptors will use Authenticators, which are already mentioned
on wiki page
https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts 
(Like RememberMeInterceptor will use RememberMeAuthenticator etc.)


USE CASE EXAMPLE:

Let's imagine that user is interested in authentication through SSO
server like OpenSSO

In this case we have interceptors like:

Request 1: User will send request to secure uri:
http://localhost:8080/app/secure

     - LoginRequiredInterceptor will recognize that it's private URI and
set AuthenticationContext.setLoginRequired(true)
     - OpenSSOInterceptor will try to find SSO token (in OpenSSO, it's
saved in cookie iplanetDirectoryPro). Token not found, so calling
redirection to OpenSSO console.

Request 2: User submits his credentials in OpenSSO console and OpenSSO
redirects user back to his application with SSO token set:
http://localhost:8080/app/verifyssologin

     - OpenSSOInterceptor will find SSO token in request. It will save
it into AuthenticationContext and then call
OpenSSOAuthenticator.authenticate(authenticationContext)
     - OpenSSOAuthenticator will use OpenSSO agent to do verification of
SSO token by communicating with OpenSSO server. It will return
AuthenticationStatus.SUCCESS and save it into AuthenticationContext if
SSO token verification is successful

> Looking at the initial API I just wonder is it also starting to follow
> the same assumptions.  Picking username / password authentication as a
> first step whilst it may be simple historically has led us into
> situations where adding more complex scenarios end up being added as a
> workaround.
>
> I suppose the real question is where would this be used, is this
> something that would only be used within apps that want to establish
> some form of 'security context' with an identity or could this also be
> used in other locations such as valves implementing http
> authentication.  If the former than maybe not a huge issue but if the
> latter this API could be repeating the problems of the past.
>
> Regards,
> Darran Lofthouse.
>
>