Re: [ANNOUNCE] Release of Apache DeltaSpike
Congratulations on getting the first release out! -M On Sun, Feb 12, 2012 at 11:22 PM, Gerhard Petracek gpetra...@apache.org wrote: The Apache DeltaSpike team is pleased to announce the first release (v0.1-incubating). DeltaSpike consists of a number of portable CDI extensions that provide useful features for Java application developers. The goal of DeltaSpike is to create a de-facto standard of CDI-Extensions that is developed and maintained by the community. Apache DeltaSpike is available in the central Maven repository under Group ID org.apache.deltaspike.*. Release Notes: http://s.apache.org/DeltaSpike_01incubating With this first step we started to merge Apache MyFaces CODI-Core and JBoss Solder. We will release early and often. So take the chance and test the first features provided by this release. In the next release we will add further DeltaSpike-Core features and we will start with further modules. We would be happy to receive your feedback to improve Apache DeltaSpike step by step. Enjoy! Gerhard Petracek -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] [Updated] (DELTASPIKE-77) review and discuss Identity API
[ https://issues.apache.org/jira/browse/DELTASPIKE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-77: --- Affects Version/s: 0.1-incubating Summary: review and discuss Identity API (was: review and discuss Identity) review and discuss Identity API --- Key: DELTASPIKE-77 URL: https://issues.apache.org/jira/browse/DELTASPIKE-77 Project: DeltaSpike Issue Type: Sub-task Components: Security-Module Affects Versions: 0.1-incubating Reporter: Shane Bryzak Assignee: Shane Bryzak -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Identity API
Hi,
I think it is also important that you can work with permissions. It is
much more fine grained then roles but more flexible. It becomes much easier
to change what a group of people can do, even without changing the code. I
never use roles in an application, only permissions.
I'm not saying we need to do the implementation of it by default in
deltaspike but should have at least something like
boolean hasPermission(String permissionName)
in the identity API.
my idea about security.
regards
Rudy
On 12h February 2012 23:33, Shane Bryzak sbry...@redhat.com wrote:
I've created an umbrella issue to track the work we do on the security
module [1], and the first task is to review and discuss the Identity API.
This API forms the core of the security module, and all other features
build on top of it to implement a complete security framework.
The Identity interface represents an individual, current user of an
application and its implementation must be session-scoped to provide
security services for the entirety of a user's session. I'm going to paste
the (slightly modified) code from Seam as it's mostly well documented, and
so we have a baseline from which to further discuss:
public interface Identity {
public static final String RESPONSE_LOGIN_SUCCESS = success;
public static final String RESPONSE_LOGIN_FAILED = failed;
public static final String RESPONSE_LOGIN_EXCEPTION = exception;
/**
* Simple check that returns true if the user is logged in, without
attempting to authenticate
*
* @return true if the user is logged in
*/
@Secures
@LoggedIn
boolean isLoggedIn();
/**
* Returns true if the currently authenticated user has provided their
correct credentials
* within the verification window configured by the application.
*
* @return
*/
boolean isVerified();
/**
* Will attempt to authenticate quietly if the user's credentials are set
and they haven't
* authenticated already. A quiet authentication doesn't throw any
exceptions if authentication
* fails.
*
* @return true if the user is logged in, false otherwise
*/
boolean tryLogin();
/**
* Returns the currently authenticated user
*
* @return
*/
User getUser();
/**
* Attempts to authenticate the user. This method raises the following
events in response
* to whether authentication is successful or not. The following events may
be raised
* during the call to login():
* p/
* org.apache.deltaspike.**security.events.LoggedInEvent - raised when
authentication is successful
* org.apache.deltaspike.**security.events.**LoginFailedEvent - raised
when authentication fails
* org.apache.deltaspike.**security.events.**AlreadyLoggedInEvent - raised
if the user is already authenticated
*
* @return String returns RESPONSE_LOGIN_SUCCESS if user is authenticated,
* RESPONSE_LOGIN_FAILED if authentication failed, or
* RESPONSE_LOGIN_EXCEPTION if an exception occurred during authentication.
These response
* codes may be used to control user navigation. For deferred
authentication methods, such as Open ID
* the login() method will return an immediate result of
RESPONSE_LOGIN_FAILED (and subsequently fire
* a LoginFailedEvent) however in these conditions it is the responsibility
of the Authenticator
* implementation to take over the authentication process, for example by
redirecting the user to
* another authentication service.
*
*/
String login();
/**
* Attempts a quiet login, suppressing any login exceptions and not creating
* any faces messages. This method is intended to be used primarily as an
* internal API call, however has been made public for convenience.
*/
void quietLogin();
/**
* Logs out the currently authenticated user
*/
void logout();
/**
* Checks if the authenticated user is a member of the specified role.
*
* @param role String The name of the role to check * @param group String
the name of the group in which the role exists
* @return boolean True if the user is a member of the specified role
*/
boolean hasRole(String role, String group);
/**
* Adds a role to the authenticated user. If the user is not logged in,
* the role will be added to a list of roles that will be granted to the
* user upon successful authentication, but only during the authentication
* process.
*
* @param role The name of the role to add * @param group The name of the
group in which to create the role
*/
boolean addRole(String role, String group);
/**
* Checks if the authenticated user is a member of the specified group
*
* @param name The name of the group
* @return true if the user is a member of the group
*/
boolean inGroup(String name);
/**
* Adds the user to the specified group. See hasRole() for semantics in
* relationship to the authenticated status of the user.
*
* @param name The name of the group
* @return true if the group was successfully added
*/
boolean addGroup(String name);
/**
* Removes the currently authenticated user from the specified group
*
*
Re: [DISCUSS] Identity API
On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote: Some particular points to review: 1. Should we attempt to use the security classes provided by Java SE, such as Principal, Subject, etc or use our own User API - this will affect what is returned by the getUser() method above. Keep in note that we will have at least a simple User/Role/Group API as part of Identity Management. In Seam 2 we originally used the built-in Java classes (which made more sense because the authentication process was based on JAAS), however in Seam 3 (where we removed JAAS because it doesn't support asynchronous authentication as required by OpenID etc) we based the security module on the PicketLink User API. IMHO, this is not a critical choice either way - the Java security classes have the advantage of being familiar to many users, while on the flipside if we provide our own User API we have the flexibility of being able to extend it in the future. So both options have their own advantages. 2. The addRole() and addGroup() methods are intended to be only used during the authentication process to grant particular user memberships for the duration of their session only. A few users have found this a little confusing, as they were using identity management, and expected these methods to grant a permanent membership for the user. One solution may be to simply rename these methods to addSessionRole() and addSessionGroup() - thoughts? This implies question if API related to authentication and IDM operations should be de coupled or not - as this would be side effect of relying on Java SEE security classes. 3. We're touching a little bit on the authorization API here also with the hasRole() / inGroup() methods. I'll provide a quick description of these core security API concepts here: * User - represents an individual user of an application. Can either be human or non-human, and can represent either a user managed locally (i.e. through the IDM API) or an externally authenticated User, such as one that has logged in with OpenID. * Group - a collection of users and other groups. The intent is that privileges can be either assigned to individual users, groups or roles. Groups have a hierarchical structure and can be a member of zero or more other groups. I would personally vote for having clear three structure - so group can belong to zero (under root) or 1 other group (parent). Having flexible hierarchy leads to fairly complex structure. This can easily lead to more cluttered API. From my observations tree structure covers 95% of use cases and many organizations need to integrate with their LDAP which is exactly this kind of shape. * Role - represent a particular real life role of a user. Roles are defined as a three-way relationship between user, group and role type. For example, user Bob might be an accounts clerk (the role type) at head office (the group). It is also possible for a user to have a role in a group, without being a member of that group. Does it imply having separate notion of membership between user and group? For me it is the same as Bob being member (the role type) at employees (the group). One thing less to cover in the API which can make it simpler. [1] https://issues.apache.org/jira/browse/DELTASPIKE-76 [2] https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java
Re: [DISCUSS] Identity API
hi shane,
i'm sure there are good reasons for most/all details. since i don't know
them, i just list the topics which come to my mind after reading the
provided information.
#tryLogin
i don't see the need for it compared to #login, because it can be done by
users easily (if needed).
at least at the beginning i would keep the api as minimal as possible. we
can add further parts based on concrete and important use-cases.
#login
uses string as return type instead of an enum.
in general : we should define a general rule for the usage of exceptions
which should be used by most deltaspike apis.
#quietLogin
is method is intended to be used primarily as an internal API call
... then it shouldn't be part of the api. (that's related to a 2nd topic.
see api vs. spi)
#hasRole
Checks if the authenticated user is a member of the specified role.
#checkRole
Checks that the current authenticated user is a member of the specified
role.
#hasRole and #checkRole look very similar - if the exception is the only
difference: see my comment about #tryLogin. at least we should think about
unified names.
#addXyz
that's a general topic we have to discuss. in myfaces codi we have all
write-methods which aren't intended to be used frequently in the spi to
keep the api simple and small ([1] and [2] illustrate it in case of the
initial refactoring of @Secured for deltaspike - the naming convention is
always Editable[ApiName]).
@type string in the api:
i know - it's easy, generic and sometimes just needed to use strings.
however, at least we should re-visit them and just use them if there is no
useful alternative.
@rudy:
i agree with you.
for v0.1 we always started to discuss the basic use-cases and requirements
and afterwards the concrete api.
imo that leads to a better api and we should try to keep this approach
(for sure the content of v0.1 was easier).
regards,
gerhard
[1] http://s.apache.org/4sL
[2] http://s.apache.org/j2E
2012/2/13 Rudy De Busscher rdebussc...@gmail.com
Hi,
I think it is also important that you can work with permissions. It is
much more fine grained then roles but more flexible. It becomes much easier
to change what a group of people can do, even without changing the code. I
never use roles in an application, only permissions.
I'm not saying we need to do the implementation of it by default in
deltaspike but should have at least something like
boolean hasPermission(String permissionName)
in the identity API.
my idea about security.
regards
Rudy
On 12h February 2012 23:33, Shane Bryzak sbry...@redhat.com wrote:
I've created an umbrella issue to track the work we do on the security
module [1], and the first task is to review and discuss the Identity API.
This API forms the core of the security module, and all other features
build on top of it to implement a complete security framework.
The Identity interface represents an individual, current user of an
application and its implementation must be session-scoped to provide
security services for the entirety of a user's session. I'm going to
paste
the (slightly modified) code from Seam as it's mostly well documented,
and
so we have a baseline from which to further discuss:
public interface Identity {
public static final String RESPONSE_LOGIN_SUCCESS = success;
public static final String RESPONSE_LOGIN_FAILED = failed;
public static final String RESPONSE_LOGIN_EXCEPTION = exception;
/**
* Simple check that returns true if the user is logged in, without
attempting to authenticate
*
* @return true if the user is logged in
*/
@Secures
@LoggedIn
boolean isLoggedIn();
/**
* Returns true if the currently authenticated user has provided their
correct credentials
* within the verification window configured by the application.
*
* @return
*/
boolean isVerified();
/**
* Will attempt to authenticate quietly if the user's credentials are set
and they haven't
* authenticated already. A quiet authentication doesn't throw any
exceptions if authentication
* fails.
*
* @return true if the user is logged in, false otherwise
*/
boolean tryLogin();
/**
* Returns the currently authenticated user
*
* @return
*/
User getUser();
/**
* Attempts to authenticate the user. This method raises the following
events in response
* to whether authentication is successful or not. The following events
may
be raised
* during the call to login():
* p/
* org.apache.deltaspike.**security.events.LoggedInEvent - raised when
authentication is successful
* org.apache.deltaspike.**security.events.**LoginFailedEvent - raised
when authentication fails
* org.apache.deltaspike.**security.events.**AlreadyLoggedInEvent - raised
if the user is already authenticated
*
* @return String returns RESPONSE_LOGIN_SUCCESS if user is authenticated,
* RESPONSE_LOGIN_FAILED if authentication failed, or
* RESPONSE_LOGIN_EXCEPTION if an exception occurred during
Re: [jira] [Created] (DELTASPIKE-61) global alternatives
I filed a Weld issue to track this (https://issues.jboss.org/browse/WELD-1066) Mark, could you comment on the issue with an example of how this is configured in OWB so that Weld is aligned if possible? Thanks. On 01/26/2012 07:09 PM, Mark Struberg wrote: yup, thats CDI-18 [1] But I fear that CDI-1.1 containers will be mainstream only in 2 years or so. Instead I'd welcome if Weld would introduce a flag (for their CDI-1.0 implementations) where this can be enabled - like OWB does. LieGrue, strub [1] https://issues.jboss.org/browse/CDI-18 - Original Message - From: Adam Warskiad...@softwaremill.pl To: deltaspike-dev@incubator.apache.org Cc: Sent: Thursday, January 26, 2012 6:46 PM Subject: Re: [jira] [Created] (DELTASPIKE-61) global alternatives Wasn't global alternative enablement a feature planned for CDI 1.1? And, besides, that's how it works in Weld currently anyway as far as I know ;) Adam On Jan 26, 2012, at 4:00 PM, Gerhard Petracek (Created) (JIRA) wrote: global alternatives --- Key: DELTASPIKE-61 URL: https://issues.apache.org/jira/browse/DELTASPIKE-61 Project: DeltaSpike Issue Type: New Feature Components: Core Affects Versions: 0.1 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2 @Alternative should work across BDAs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Adam Warski CTO, SoftwareMill http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org +48 660 703 691
Re: [jira] [Created] (DELTASPIKE-61) global alternatives
hi jozef, it's org.apache.webbeans.useBDABeansXMLScanner and i added it as comment to WELD-1066. regards, gerhard 2012/2/13 Jozef Hartinger jhart...@redhat.com I filed a Weld issue to track this (https://issues.jboss.org/** browse/WELD-1066 https://issues.jboss.org/browse/WELD-1066) Mark, could you comment on the issue with an example of how this is configured in OWB so that Weld is aligned if possible? Thanks. On 01/26/2012 07:09 PM, Mark Struberg wrote: yup, thats CDI-18 [1] But I fear that CDI-1.1 containers will be mainstream only in 2 years or so. Instead I'd welcome if Weld would introduce a flag (for their CDI-1.0 implementations) where this can be enabled - like OWB does. LieGrue, strub [1] https://issues.jboss.org/**browse/CDI-18https://issues.jboss.org/browse/CDI-18 - Original Message - From: Adam Warskiad...@softwaremill.pl To: deltaspike-dev@incubator.**apache.orgdeltaspike-dev@incubator.apache.org Cc: Sent: Thursday, January 26, 2012 6:46 PM Subject: Re: [jira] [Created] (DELTASPIKE-61) global alternatives Wasn't global alternative enablement a feature planned for CDI 1.1? And, besides, that's how it works in Weld currently anyway as far as I know ;) Adam On Jan 26, 2012, at 4:00 PM, Gerhard Petracek (Created) (JIRA) wrote: global alternatives --- Key: DELTASPIKE-61 URL: https://issues.apache.org/** jira/browse/DELTASPIKE-61https://issues.apache.org/jira/browse/DELTASPIKE-61 Project: DeltaSpike Issue Type: New Feature Components: Core Affects Versions: 0.1 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2 @Alternative should work across BDAs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/**jira/secure/**ContactAdministrators!default. **jspahttps://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/** software/jira http://www.atlassian.com/software/jira -- Adam Warski CTO, SoftwareMill http://twitter.com/#!/**adamwarski http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org +48 660 703 691
Re: release branches
+1 regards, gerhard 2012/2/13 Mark Struberg strub...@yahoo.de I'd say we just push the release-branch + the release-tag and then merge them over to master. This is only needed to upgrade the versions. LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike deltaspike-dev@incubator.apache.org Sent: Monday, February 13, 2012 1:49 PM Subject: release branches hi @ all, since a new commit was pushed before we merged back the release branch, we have to discuss release branches right now. the options i see right now are: 1) we push the external named release-branch as it is (+ tag) and rebase the master 2) we merge the external release branch locally and just push the result as i did with the master at [1] 3) we don't allow pushes (in the future) before we pushed the fast forwarded master. regards, gerhard [1] https://github.com/os890/DS_Discuss
[jira] [Created] (DELTASPIKE-83) unit and integration tests for global alternatives
unit and integration tests for global alternatives -- Key: DELTASPIKE-83 URL: https://issues.apache.org/jira/browse/DELTASPIKE-83 Project: DeltaSpike Issue Type: Sub-task Components: Tests Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.2-incubating -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
