1

The Java EE application we are currently finalizing makes use of JBoss PicketLink and Apache DeltaSpike for its security framework. All authentication and authorization decisions are done using these libraries. Because of our high security requirements, most of our EJB service methods have authorization checks. In some instances, an unprivileged user would need to perform a privileged action. For example, only users in the Admin role are allowed to create user accounts. However, during user self-registration a user account would need to be created. Typically, we would use something like "Run As" for this sensitive operation so that for a single call the unprivileged user would have permission to perform a privileged action.

I have not, however, seen anything within the PicketLink documentation or examples that suggests that PicketLink supports this functionality. I know of other security frameworks that do. Java EE even supports this via the @RunAs annotation. We'd prefer not doing this with annotations, however, as we want very fine-grained control over where this can be applied.

Can anyone point me towards any documentation or examples that would explain how to do this? Is this functionality supported within PicketLink? Or are we out of luck? Do you have a different methodology we could use to address this type of situation and requirements?

Shadowman
  • 11,150
  • 19
  • 100
  • 198
  • Are you using XACML inside PicketLink? The Run As feature is typically achieved as a combination of the authenticaton framework and a policy making use of an attribute e.g. onbehalfof... – David Brossard Feb 04 '16 at 20:54
  • No. Not using XACML. That seems like a far more heavyweight addition than we think we need at this point. – Shadowman Feb 04 '16 at 21:06
  • XACML is not heavyweight but given your use case it sounds like you need the authentication layer to handle impersonation – David Brossard Feb 04 '16 at 23:07

1 Answers1

0

There should be no need for Run As. If unauthenticated users are allowed to self-register, then you shouldn't blanket restrict user creation to admins. By definition, anything an unprivileged user can do is not a sensitive action. If admins have more flexibility in creating user accounts, then code two service methods: The one that admins use to create user accounts for others, and the more restricted one that unauthenticated users use to self-register.

Ken Clubok
  • 1,238
  • 6
  • 11
  • User registration is only one example of where we need this functionality. There are other times when a privileged action may need to be performed when there is no authenticated user (for example, an asynchronous process kicked off by an MDB) – Shadowman Feb 10 '16 at 18:39
  • The asynchronous process is a better example. Personally, I tend to use PicketLink for authentication, but not for authorization, especially when authorization requirements reach a certain threshold of complexity. Authorization is easy enough to handle at the application level. – Ken Clubok Feb 12 '16 at 04:13