Told you they would laugh. :) But let me rephrase the phrase that got me in 
trouble. Almost all of the integration examples at the time I wrote that code 
dealing with DS made use of security annotation. Actually I did looked at 
Identity w/in picketlink and tried to make use of it. I really just wanted it 
to behave like the old Seam identity object. Of course being the DS noob I am, 
after about a week of not moving at the pace I needed to I decided to alter 
course. Other than having difficulty getting my producer to behave as expected, 
most of the trouble I had w/ the picket-link integration really came when I 
tried to cluster the application. Clustering it definitely deserves a more 
rigorous testing phase.

My user experience with DS has really forced me to learn more of what 
frameworks once obscured from the average programmer and enabled me (like Mark 
said) to cherry pick anything I want to use... even my square wheel :)

best regards,

Nathan Dennis | Software Developer
732 Greenwood Street | Albemarle, NC | 28001
Main (800) 230-7525 | Direct: 704-986-7211 | Mobile 704.984.0829
www.monarchnc.org | [email protected]



-----Original Message-----
From: Mark Struberg [mailto:[email protected]]
Sent: Wednesday, September 04, 2013 4:55 PM
To: [email protected]
Subject: Re: deltaspike and authorization

+1

the main reason we did no specific binding was that we feel that CDI 
integration is best done on their end.
It would simply be really hard for DeltaSpike to provide bindings for n 
versions of m different IDM and security systems.
There are just too many of them around (and most are actually decent or even 
very good). And by forcing them into a common API we would probably end up 
loosing way too many individual strength of those systems.

Instead we focused on providing a system (SecurityBinding) which allows for 
easy integration into any external system you like.

LieGrue,
strub




>________________________________
> From: Jason Porter <[email protected]>
>To: [email protected]
>Sent: Wednesday, 4 September 2013, 22:12
>Subject: Re: deltaspike and authorization
>
>
>DeltaSpike isn't all about annotations, we simply decided not to do
>much in the security realm and left that up to other providers. Your
>code certainly works, may not be the best way to do it, but it works.
>Have you taken a look at
>https://github.com/picketlink/picketlink/blob/master/api/src/main/java/
>org/picketlink/Identity.java
>?
>You'll probably have to use a producer for it, but it looks like it
>should give you what you need.
>
>
>On Wed, Sep 4, 2013 at 11:57 AM, Nathan Dennis
><[email protected]>wrote:
>
>> Multiple ways of going about this... but since DS was all about
>> annotations (and Mark and Jason will probably laugh at this.. but)
>>
>> @Named("inlineSecuritiesBean")
>> @RequestScoped
>> public class InlineSecuritiesBean {
>>
>>
>>         public boolean isAdmin(){
>>                 boolean result = false;
>>                 try {
>>                         result = executeAdmin();
>>                 } catch (Exception e) {
>>                         //e.printStackTrace();
>>                         //log something
>>                 }
>>                 return result;
>>         }
>>
>>         @Admin
>>         private boolean executeAdmin() {
>>                 return true;
>>         }
>>
>>
>> ......
>> Used this type of structure for each of my roles I defined. Not quite
>> as slick as the old seam way.. but this way I could use it pretty
>> much anywhere without extending or maintaining a session bean with a
>> role list in it and test with the whole array.contains mess. just use
>> the annotations and let DS do the rest.
>>
>>
>>
>>
>> best regards,
>>
>> Nathan Dennis | Software Developer
>> 732 Greenwood Street | Albemarle, NC | 28001 Main (800) 230-7525 |
>> Direct: 704-986-7211 | Mobile 704.984.0829 www.monarchnc.org |
>> [email protected]
>>
>>
>>
>> -----Original Message-----
>> From: Kelly Goedert [mailto:[email protected]]
>> Sent: Wednesday, September 04, 2013 1:50 PM
>> To: users
>> Subject: deltaspike and authorization
>>
>> Hi,
>>
>> using the direction given to me in my previous question, I was able
>> to implement an authentication mechanism in my app using picketlink.
>>
>> I remember that in seam 3, I could use something like this on a xhtml
>> <h:commandButton ... rendered="#{identity.hasRole('some role
>> name')}">
>>
>> I could not find this in picketlink. According to this page
>> https://docs.jboss.org/author/display/SECURITY/PicketBox+CDI#PicketBo
>> xCDI-IdentityManagement
>> it
>> is not available. Is there anything on deltaspike to implement this?
>>
>> Or I should be asking this on a picketlink forum?
>>
>> Thanks
>>
>> Kelly
>>
>>
>> [http://monarchnc.org/images/monarch/env.png]Please consider the
>> environment before printing this email.
>> WARNING: This email is intended solely for the person or entity to
>> which it is addressed and may contain confidential and/or privileged 
>> information.
>> Any review, dissemination, copying, printing or other use of the
>> email by persons or entities other than the addressee is prohibited.
>> If you have received this email in error, please contact the sender
>> immediately and delete the material from any computer. If you are
>> unable to determine the sender of this email, please email Monarch at
>> [email protected] or contact us at toll free (800) 230-7525, and advise 
>> us of the error.
>>
>
>
>
>--
>Jason Porter
>http://en.gravatar.com/lightguardjp
>
>
>


[http://monarchnc.org/images/monarch/env.png]Please consider the environment 
before printing this email.
WARNING: This email is intended solely for the person or entity to which it is 
addressed and may contain confidential and/or privileged information. Any 
review, dissemination, copying, printing or other use of the email by persons 
or entities other than the addressee is prohibited. If you have received this 
email in error, please contact the sender immediately and delete the material 
from any computer. If you are unable to determine the sender of this email, 
please email Monarch at [email protected] or contact us at toll free (800) 
230-7525, and advise us of the error.

Reply via email to