Stormpath customData access

[cha55son]

I have looked all over the place but can't seem to find how to access the customData for a logged in user. The stormpath-shiro plugin is setup and working. I can login as a user and the permissions are correct as well. I just need to be able to access the customData provided by stormpath.

Here is my code (jRuby on Rails):

    token = UsernamePasswordToken.new(username, password)
    token.setRememberMe(false)
    begin
        current_user.login(token)
        puts current_user.getPrincipals() # Doesn't contain the custom data.
        ...
        # Not sure how to access the customData for the logged in user.
        # Any help would be greatly appreciated.

[mrioan]

Hi @cha55son,

the ApplicationRealm holds a Stormpath Client instance that you can use to interact with Stormpath. You can obtain it this way:

ApplicationRealm applicationRealm = (ApplicationRealm)((RealmSecurityManager) SecurityUtils.getSecurityManager()).getRealms().iterator().next();
Client client = applicationRealm.getClient();

Then, you can obtain the CustomData of the currently logged in Account this way:

String accountHref = (String) SecurityUtils.getSubject().getPrincipal();
Account account = client.getResource(accountHref, Account.class);
CustomData customData = account.getCustomData();

Please let me know if you need any other clarification.
Regards!

[cha55son]

Thanks for the quick reply. I'll try this out and get back to you.

[jbunting]

Would a patch to ApplicationRealm be considered to make this viable?

I'm thinking about something like this: https://gist.github.com/jbunting/f12588db598740fc2e2c

[lhazlewood]

@cha55son do you know if jRuby on Rails uses the Servlet API 'under the hood'?

I'm working on adding nicer Servlet support to the Stormpath SDK for Java that makes this easier and I'm curious if this could eventually be leveraged in your environment.

[lhazlewood]

@jbunting I'm not sure that's a good idea just yet. Principals are often serialized to the browser as an encrypted cookie. Like sessions, the best practice for Shiro Principals is to keep them as minimal as possible, preferably just having one or two 'pointers' that can be used to look up the 'real' data from a (cached) data store on demand.

Like sessions, the more you put in them, the more they start to impact application performance, as that is state that needs to be serialized and distributed on demand.

As a tangent to this, the Servlet support I'm working on allows one to save a Stormpath Resource to the HttpSession, but under the hood, just the resource class name and the href is saved. On later retrieval (e.g. session.getAttribute("account'), the name+href pair are reconstituted to the corresponding Resource instance (e.g. in this example, an Account).

Something similar currently exists at the request level, e.g.:

HttpServletRequest request = ...
RequestAccountResolver resolver = new DefaultRequestAccountResolver();
if (resolver.hasAccount(request)) {
    Account account = resolver.getAccount(request);
    //user is known (but not necessarily authenticated - could be from 'rememberMe' too)
} //else request is not associated with a known account yet

which depends on existence via request.getAttribute (so sessions aren't required, allowing for support in a stateless web environment, like a REST API).

But again, this is all Servlet-specific stuff. I'm curious what other environments might be helpful.

[jbunting]

@lhazlewood - understood... My thinking was to make this configurable at the system level, making the decision as to what was "too much" a system-dependent thing. Without configuring special "customData mappings", this code shouldn't have any effect (provided I make one fix to not hit the stormpath API if nothing is configured).

My goal here was to allow flexibility in a way that our application doesn't have to have stormpath-specific code. It is usually deployed with an LDAP or INI backing, so we wanted to keep it somewhat generic. In addition we are only looking to add a few custom fields, nothing that should change the performance profile from what it is with the few fields that are already added.

Note - @cha55son and I are working on the same application.

[lhazlewood]

@jbunting makes sense, thanks for the clarification. This still might be possible (as a map that proxies a resource for example). Does the stuff you're using use the Servlet API at all? or no?

[jbunting]

Yep, it sure does. We're using rack-servlet to serve everything up.

[lhazlewood]

Cool - that's helpful. I wonder if httpServletRequest.getUserPrincipal() could be used? That still might require an Stormpath-SDK-specific Principal class implementation though :/

[lhazlewood]

Side note: dangit! I wish Shiro 2.0 was out. That way you could use the new Account concept with account.getAttributes() which would just return a Map

[lhazlewood]

er, I mean subject.getAttributes().get("username")

[jbunting]

Side note: I now feel really guilty for not having found a chance to look at shiro 2.0.

We may just fork stormpath-shiro for now and anticipate 2.0 to do this right. The account concept definitely sounds like a cleaner and portable way to accomplish what we're trying to.

[lhazlewood]

lol, no worries - I feel guilty for not being able to try and get us to release 2.0 earlier! If you do fork, and you feel like the additions might still be useful, please do send a pull request. Otherwise we'll definitely make this shiro 2.0 compatible as soon as we can.