[PicketBox 5] - Authentication API
by Pedro Igor Silva
Hi All,
I would like to know your opinion about the authentication API that is being used by PicketBox 5.You can check an initial documentation here: https://docs.jboss.org/author/display/SECURITY/PicketBox+Authentication+API.
We are considering some requirements during the construction of this API. They are as follows:
- Easy-to-use and fast to get started;
- Flexible architecture providing ways to use different mechanisms like Username/Password, Digest, Certificates, SASL, etc;
- Unified authentication API. Although you can use different mechanisms, the API usage is the same;
- Allow authentication using multiple stores: properties, databases, ldap, etc;
- Hide mechanism`s complexity from users. Users do not need to be aware of the complexities behind a specific mechanism;
- Environment agnostic. You can use it in a pure Java SE application and in a JEE/CDI environment as well;
- Challenge/Response design;
- Authentication Events. Users should be able to observe specific authentication events like pre/pos authentication, failures, etc.
- Auditing.
Regards,
Pedro Igor
14 years
Moving DeltaSpike security to PicketLink
by Shane Bryzak
Hey guys,
I'm just looking at the infrastructure we have for doing this, currently
in the PicketLink github repo [1] we have picketlink-idm and cdi
repositories set up. I propose that we rename picketlink-idm to
picketlink-idm-legacy to make way for the new picketlink-idm, and rename
cdi to picketlink-cdi (this module will then contain all the CDI and
DeltaSpike integration for PicketLink IDM, plus some authorization
features such as ACLs and permission management). Are there any
objections to this?
Shane
[1] https://github.com/picketlink
14 years
securing JSON
by Bill Burke
I think you should contribute to the Jackson project to implement JSON
security. I'm assuming JSON security means encrypting various pieces of
a json document? all the stuff we have in XML land?
Also, I still never understood why somebody would want a partial
encryption of a document. Why not just send it via S/MIME?
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
14 years
security domain solely as a metadata store
by Bill Burke
I want to discuss a bit about what a AS7/Pickelink security domain's
responsibilities should be in the new architecture. Currently the
responsibilities of the security domain are blurred. Sometimes its just
a metadata store (user/password), sometimes it partially implements a
security protocol, sometimes it implements all of a protocol.
I'd like to make the case that the security domain is solely a metadata
store and that it should not handle anything protocol related. Protocol
related processing should be done in a Web filter/valve, EJB
interceptor, or whatever is available at the protocol level.
Picketbox should be a set of utilities for helping to build security
protocols.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
14 years
Fwd: DeltaSpike, IDM, Authentication and Authorization
by Pete Muir
Begin forwarded message:
> From: Pete Muir <pmuir(a)redhat.com>
> Subject: DeltaSpike, IDM, Authentication and Authorization
> Date: 27 July 2012 15:17:42 GMT+01:00
> To: security-dev(a)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-...
>
> 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
14 years
