[security-dev] DeltaSpike, IDM, Authentication and Authorization
Pete Muir
pmuir at redhat.com
Fri Jul 27 12:35:35 EDT 2012
On 27 Jul 2012, at 16:53, Jay Balunas wrote:
> Note: I'm not asking you [Pete] to have all of these answers. I just wanted to bring them up for discussion, and clarification.
:-) Let me propose some ideas...
>
> How will PicketLink IDM interact with or integrate with DeltaSpike security api/spi?
Under the current proposed DeltaSpike security feature set (which is available already in 0.2), DS provides an very thin authentication and authorization API and SPI.
I think it's best if I give you a short walk through.
Authentication
-------------------
https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24ae22b9850e643bffe54/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/api/Identity.java
This contains methods to log in, log out, get the current user, and check if a user is logged in or not. In order to log in/log out, a LoginCredential is provided:
https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24ae22b9850e643bffe54/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/api/credential/LoginCredential.java
We also have a very basic representation of a user, which contains some unique identifier for the user:
https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24ae22b9850e643bffe54/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/api/User.java
This isn't useful on it's own of course, but would plug into whatever IDM solution you happen to use. In our case PicketLink IDM.
Authentication will also send a number of CDI events, allowing the application, and other frameworks/libraries, to respond to authentication events.
On the SPI side, we have a pluggable Authenticator, which is responsible for actually performing the authentication against whatever backend/provider you are using:
https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24ae22b9850e643bffe54/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/spi/authentication/Authenticator.java
As you can see, you need to implement the authentication method (the implementation should inject the current LoginCredential), there is a postAuthenticate callback (in case for some reason the authenticator needs to update some record like a successful login attempt). The current authentication status can be read, as well as the user that has been authenticated.
As I mentioned, the Authenticator is pluggable, and is set using https://github.com/apache/incubator-deltaspike/blob/5e4a7eb4de01004206f24ae22b9850e643bffe54/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/spi/authentication/AuthenticatorSelector.java
Let me give an example of this in use
// Example of a way to configure the authenticator in use
public void setAuthenticator(@Observes PreAuthenticateEvent evt, AuthenticatorSelector selector) {
selector.setAuthenticatorClass(MySecretKeyAuthenticator.class); // TODO I would like to be able pass in an object here, I'll raise an issue...
}
// Tests are often a good way to understand an API :-)
@Inject Identity identity;
@Inject LoginCredential credential;
@Test
public void loginTest() {
credential.setUserId("pmuir");
credential.setCredential(new MySecretKeyCredential("password"));
AuthenticationResult result = identity.login();
if (result == SUCCESS) {
System.out.println("logged in " + identity.getUser().getId());
} else {
System.out.println("log in failed :-(((");
}
}
Authorization
------------------
You can either define your own security bindings, just like you define a qualifier etc. or use the voters with @Secured.
This is covered by http://incubator.apache.org/deltaspike/security.html
IDM Integration
---------------------
The IDM should be tightly integrated into authentication, and PicketLink CDI would automatically configure an app to use PicketLink IDM as the authenticator, if IDM is enabled (see the setAuthenticator observer above, this would not be required in this case).
Authorization doesn't plug straight into pure IDM, but instead plugs into a permission resolver, which in turn uses the IDM in order to turn the rights of a user into permissions to perform an action. This would come as part of PicketLink IDM AIUI.
I need to do a bit more research here to complete the picture. I'll try to ping back in a bit.
> Will users of DeltaSpike security somehow configure PicketLink-IDM to manage the applications users?
I would imagine that if you:
* bundle DS security
* bundle PicketLink IDM
* bundle PicketLink CDI
then this will automatically turn on
> Or would it literally be separate i.e. an app uses DS APIs, and separately sets up IDM with PL?
This would of course be possible, but I suspect not the default.
>
> Would there be a UI for this, even if it's just a default/basic one?
This is not a requirement from my side.
> If so where would it exist?
Per above, I'll defer on this
> Would the PicketLink IDM provide it as an example?
I would prefer this to be a separate module/project to PicketLink IDM, which should concentrate on the programming model (which a web console would use of course).
>
> -Jay
>
>
> On Jul 27, 2012, at 10:20 AM, Pete Muir wrote:
>
>>
>>
>> Begin forwarded message:
>>
>>> From: Pete Muir <pmuir at redhat.com>
>>> Subject: DeltaSpike, IDM, Authentication and AuthorizationA
>>> Date: 27 July 2012 15:17:42 GMT+01:00
>>> To: security-dev at lists.jboss.org
>>>
>>> Until recently, it looked like Apache DeltaSpike would define an IDM API, but now it looks like most people are in agreement that DeltaSpike should not cover IDM.
>>>
>>> http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/IDM-impl-feedback-td4653444.html
>>>
>>> It would still provide an API and SPI for authentication and authorization, as defined in http://incubator.apache.org/deltaspike/security.html
>>>
>>>
>>> Does it matter that DeltaSpike won't do IDM?
>>> ------------------------------------------------------------
>>>
>>> The big reason for us to do things in DeltaSpike, is to give our users a portable way to write applications. As DeltaSpike is a collaborative project between individuals and companies, there is lots of effort put into ensuring portability, and provides a good vendor neutral location to do that. If we consider where portability matters:
>>>
>>> * in application code, typically measured by the number of classes, views etc. in a typical application that must be changed to move between frameworks/libraries/runtimes
>>> * in configuration, typically measured by number of files that must be altered to move between frameworks/libraries/runtimes
>>>
>>> Typically the number of classes is much greater than the number of configuration files.
>>>
>>> We can use this to "measure" how much portability matters for a given topic, by looking at the number of files that must be changed to move between frameworks/libraries/runtimes.
>>>
>>> Taking our security topics:
>>>
>>> * Authentication: typically impacts a low number of classes and views. Some configuration required. Portability doesn't matter too much
>>> * Authorization: typically impacts most classes and views. Portability is critical.
>>> * Identity Management: typically impacts very a very few classes, and some configuration. Perhaps the only real impact on code is accessing user information for display (e.g. the classic "Welcome Pete"). This can easily be encapsulated by a single application class, and is perhaps a pattern we should recommend
>>>
>>> Therefore, we can see that whilst portability in IDM would be nice, it's not critical.
>>>
>>>
>>> Do we (JBoss) need IDM? Is there a demand for IDM in the community?
>>> -------------------------------------------------------------------------------------------------
>>>
>>> I believe the short answer, and one we are all agreed on, is yes and yes :-)
>>>
>>>
>>> How do we move forward?
>>> ------------------------------------
>>>
>>> The proposal is that we rehouse the IDM work done by Shane so far in PicketLink IDM [1]. This would consist of:
>>>
>>> * An IDM API
>>> * An IDM SPI (to allow IDM providers to be written)
>>> * An IDM impl (which loads the relevant provider and delegates calls to it)
>>> * A set of providers for the SPI such as JPA, LDAP etc.
>>>
>>> Both of these would be plain Java SE implementations, with minimal dependencies to allow maximum reuse by other JBoss projects.
>>>
>>> Furthermore, we would provide PicketLink CDI, which would provide an implementation of the authorization and authentication provider SPIs in DeltaSpike, that use the IDM backend. The module would also contain authorization providers for the various authorization frameworks PicketLink supports, as well provide authentication API implementations as needed.
>>>
>>> When will this be ready?
>>> --------------------------------
>>>
>>> I'll let Shane chime in here, but I hope we can get something out fast, as we have a lot of code today.
>>>
>>> Thoughts?
>>>
>>> Pete
>>
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>
More information about the security-dev
mailing list