Design Document – PicketLink extension for context and level based authentication and authorization

Version 4

    What

    Add to current authorization in PicketLink and project tied with it option to be aware of context and authentication method of the user performing the tasks. For example for some actions it would require the user to be logged from inner company network or use stronger authentication method. Every secured action (both methods and permissions) could have defined “security level”, which the user had to posses to be able to perform it. Level would be determined by authenticator and context. Context would be possible to be obtained by programmer defined methods, similarly to authenticators.

     

    Why

    Today applications sometimes need security based not only on simple authentication of an user, but also on the context of where the user is, what time he logs in and other contextual properties. This lets the application decides how to threat the user he shows some suspicious or unusual behavior. It can also be used for generating context-based content and behavior of the application. With that type of enhanced security management would be for example possible to force stronger authentication for admin actions, or for people working from home or in unusual hours. It could even recognize such suspicious behavior like logging in system in small time intervals from places far away (and thus raising flag for hacked/stolen/shared account), etc. It would grant the developers one more tool to secure their application to suit their needs.

     

    How

    The methods and permissions would have defined security level an user needs to poses to be able to run proceed them. With permissions it is pretty straight-forward. With methods – there could be one more annotaion @Level or add the level as property of the securing annotation. Level would be checked similarly to permissions with DeltaSpike integration and own resolver for the annotation. In case of right permission but wrong level there would occur Authentication exception with set violation in it. It would be on developer how he would handle it (I'd suggest message in style “You have to perform some kind of stronger authentication in order to do this” and possibility to redirect to different authenticator). Level of the user would be held in IdentityBean and determined in two steps - when the bean is created (level of the context) and when the user logs in (level of the authenticator).

     

    Discuss:

    1. Let the user define own strategies for (context X authenticator) level decisions? Something like LevelDecider based on context(s) of user and used authenticator and other additional informations – like user Roles. (I can imagine situations where it can be needed, it could implement such task like give user level L if he has role X and logs from place P, but he did not make more then Y logins in last hour).

     

    Proof of concept

    I developed some proof of concept where most of the things I stated here are implemented. You can check it on GitHub. The code is missing javadocs, tests and sometimes might be a bit untidy.