T5.3.7 + Tynamo Security - User ASO creation after authc/authz

[Daniel Jue <te...@gmail.com>]

Hi, I'm getting hung up on something that's probably really simple to fix.
I have a Tomcat+LDAP configuration that is doing Authc and Authz for
me--All I have to do is look in the request header to see the user
principal and log the dude/dudette in.

So I'm using the built in factory.authc filter on some of my paths that
need protecting.

Here's where I'm at:  In the legacy code I have now, the user would have a
G_User.class ASO created on the Layout component (my own class to hold user
stuff).  I'd like to move that ASO creation closer to the code where the
user is deemed authenticated (i.e. outside of a particular component or
page).   I feel like this is possible, I'm just missing something.

There's some user class creation stuff going on inside of the
FederatedAccounts test application UserRealm, but it's not setting an ASO.

Should I be setting the ASO in a custom Realm or ??

Also, I've added the code in my module for contributing to the
ApplicationStateManager for creating/retrieving a G_User.  However it
doesn't seem to be affecting anything.

Some assumptions for our case:
By the time the user gets to our T5 app, they have already been authc/authz
by the external SSO provider.

If the user has never logged in before (ie.
UserDAO.getUser(username)==null) then we register the new guy
(UserDAO.registerNewUser(foo))  and then set his ASO to the newly created
one.  If his account was not null, then we set it as the ASO.



Thanks,

Dan

Re: T5.3.7 + Tynamo Security - User ASO creation after authc/authz

[Kalle Korhonen <ka...@gmail.com>]

On Wed, Apr 29, 2015 at 12:41 PM, Daniel Jue <te...@gmail.com> wrote:

> Hi, I'm getting hung up on something that's probably really simple to fix.
> I have a Tomcat+LDAP configuration that is doing Authc and Authz for
> me--All I have to do is look in the request header to see the user
> principal and log the dude/dudette in.
>
> So I'm using the built in factory.authc filter on some of my paths that
> need protecting.
>
> Here's where I'm at:  In the legacy code I have now, the user would have a
> G_User.class ASO created on the Layout component (my own class to hold user
> stuff).  I'd like to move that ASO creation closer to the code where the
> user is deemed authenticated (i.e. outside of a particular component or
> page).   I feel like this is possible, I'm just missing something.
>
> There's some user class creation stuff going on inside of the
> FederatedAccounts test application UserRealm, but it's not setting an ASO.
>
> Should I be setting the ASO in a custom Realm or ??
>

The ASO and authentication are orthogonal concepts. Especially given that
you only have authenticated users in your T5 app, you want to create the
ASO after the user is authenticated.

For the login flow, your hunch is right about looking into
federatedaccounts. However, what you want is to invoke Subject.login by the
time the subject is created by overriding SubjectFactory. Take a look at
https://github.com/tynamo/tynamo-federatedaccounts/blob/master/tynamo-federatedaccounts-rollingtokens/src/main/java/org/tynamo/security/rollingtokens/RollingTokensModule.java
and the accompanying RollingTokenAutoLoginAdvice. That code is more
complicated than you need - you don't have to create an advice but you can
simply override the service (this particular module adds an advice so that
user code can still override the SubjectFactory if needed). Your realm then
handles normal authentication/authorization based on the LdapToken that
your SubjectFactory created (using the request header).

For the ASO, you quite possibly want something like this:

    public RequestFilter buildCurrentUserFilter(final UserService
userService,
        final ApplicationStateManager applicationStateManager, final
HttpServletRequest servletRequest) {
        return new RequestFilter() {
            public boolean service(Request request, Response response,
RequestHandler handler) throws IOException {
                if (servletRequest.getRemoteUser() != null &&
!applicationStateManager.exists(CurrentUser.class)) {
                    applicationStateManager.get(CurrentUser.class);
                }
                return handler.service(request, response);
            }
        };
    }

    @Contribute(RequestHandler.class)
    public void addRequestFilters(OrderedConfiguration<RequestFilter>
configuration,
        @InjectService("currentUserFilter") RequestFilter
currentUserFilter) {
        configuration.add("currentUser", currentUserFilter,
"after:StoreIntoGlobals");
    }

    @SuppressWarnings("rawtypes")
    @Contribute(ApplicationStateManager.class)
    public void addApplicationStateCreators(MappedConfiguration<Class,
ApplicationStateContribution> configuration,
        final HttpServletRequest request, final UserService userService,
final CookieSource cookieSource) {

        ApplicationStateCreator<CurrentUser> currentUserCreator = new
ApplicationStateCreator<CurrentUser>() {
            public CurrentUser create() {
                return new CurrentUserImpl(userService, cookieSource);
            }
        };

        configuration.add(CurrentUser.class, new
ApplicationStateContribution("session", currentUserCreator));
    }

Kalle