From Anil.Saldhana at redhat.com  Wed Mar  5 20:37:20 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Wed, 05 Mar 2014 19:37:20 -0600
Subject: [security-dev] PicketLink Website with JBoss.org Bootstrap and
	Awestruct
Message-ID: <5317D150.6020407@redhat.com>

Hi All,
   the first pass at getting the website to follow the JBoss.org design 
template/guidelines.

http://www.picketlink.org


The source files driving the website are at 
https://github.com/picketlink/web-picketlink.org

Regards,
Anil

From psilva at redhat.com  Thu Mar  6 07:10:20 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 6 Mar 2014 07:10:20 -0500 (EST)
Subject: [security-dev] PicketLink Website with JBoss.org Bootstrap
	and	Awestruct
In-Reply-To: <5317D150.6020407@redhat.com>
References: <5317D150.6020407@redhat.com>
Message-ID: <1412134766.10183932.1394107820134.JavaMail.zimbra@redhat.com>

Nice !

----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
To: security-dev at lists.jboss.org
Sent: Wednesday, March 5, 2014 10:37:20 PM
Subject: [security-dev] PicketLink Website with JBoss.org Bootstrap and	Awestruct

Hi All,
   the first pass at getting the website to follow the JBoss.org design 
template/guidelines.

http://www.picketlink.org


The source files driving the website are at 
https://github.com/picketlink/web-picketlink.org

Regards,
Anil
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev

From psilva at redhat.com  Thu Mar  6 08:11:46 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 6 Mar 2014 08:11:46 -0500 (EST)
Subject: [security-dev] Picketlink / Agorava integration
In-Reply-To: <520D0CFB.10600@redhat.com>
References: <520D0CFB.10600@redhat.com>
Message-ID: <1348611740.10201717.1394111506317.JavaMail.zimbra@redhat.com>

Awesome example !

What do you think about moving this one to our quickstart repository ? 

----- Original Message -----
From: "George Gastaldi" <ggastald at redhat.com>
To: security-dev at lists.jboss.org
Sent: Thursday, August 15, 2013 2:16:43 PM
Subject: [security-dev] Picketlink / Agorava integration

Hello,

I have developed a simple application showing how to integrate 
PicketLink with Agorava.
Check this out: https://github.com/gastaldi/agorava-picketlink

Best Regards,

-- 
George Gastaldi | Senior Software Engineer
JBoss Forge Team
Red Hat

_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev

From Anil.Saldhana at redhat.com  Wed Mar 19 21:18:18 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Wed, 19 Mar 2014 20:18:18 -0500
Subject: [security-dev] PicketLink v2.6.0.CR1 is released
Message-ID: <532A41DA.5060702@redhat.com>

Hi All,
   the PicketLink team is very pleased to announce the release of 
PicketLink v2.6.0.CR1.

http://picketlink.org/announcements/v2.6.0.CR1/

We have got lots of feedback from our users and the community.  We thank 
all the members of our community.

Please take a look at all the quickstarts we have available for you to 
get *going* with PicketLink.

This is also a very good time to announce the improved look and feel of 
our website:  http://www.picketlink.org   So please feel free to surf 
the website.

The team values your feedback. So please keep them coming.

Regards,
Anil

From Anil.Saldhana at redhat.com  Thu Mar 27 12:54:34 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 27 Mar 2014 11:54:34 -0500
Subject: [security-dev] Dashbuilder project - permission implementation
Message-ID: <533457CA.1010301@redhat.com>

Hi all,
   if you look at the Dashbuilder project codebase. They have a 
Permission implementation at
https://github.com/droolsjbpm/dashboard-builder/blob/master/modules/dashboard-security/src/main/java/org/jboss/dashboard/security/PermissionManager.java

We need to get them to migrate to PicketLink Permission Implementation.

More info on the Dashbuilder project: http://www.dashbuilder.org

Regards,
Anil

From sbryzak at redhat.com  Thu Mar 27 19:02:13 2014
From: sbryzak at redhat.com (Shane Bryzak)
Date: Fri, 28 Mar 2014 09:02:13 +1000
Subject: [security-dev] Dashbuilder project - permission implementation
In-Reply-To: <533457CA.1010301@redhat.com>
References: <533457CA.1010301@redhat.com>
Message-ID: <5334ADF5.9020402@redhat.com>

We still have a few remaining issues to iron out which Pedro is 
currently working on, but I think this would be an excellent use case 
for the Permissions API.  I'm happy to assist in any way I can.

On 28/03/14 02:54, Anil Saldhana wrote:
> Hi all,
>     if you look at the Dashbuilder project codebase. They have a
> Permission implementation at
> https://github.com/droolsjbpm/dashboard-builder/blob/master/modules/dashboard-security/src/main/java/org/jboss/dashboard/security/PermissionManager.java
>
> We need to get them to migrate to PicketLink Permission Implementation.
>
> More info on the Dashbuilder project: http://www.dashbuilder.org
>
> Regards,
> Anil
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev


From Anil.Saldhana at redhat.com  Thu Mar 27 19:49:40 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 27 Mar 2014 18:49:40 -0500
Subject: [security-dev] Dashbuilder project - permission implementation
In-Reply-To: <5334ADF5.9020402@redhat.com>
References: <533457CA.1010301@redhat.com> <5334ADF5.9020402@redhat.com>
Message-ID: <5334B914.1050309@redhat.com>

I agree Shane. As we write more demo apps/quickstarts and community 
feedback, we can iron out the Permission implementation.

I have used the Permission implementation (with Drools) to create some 
integration code for Apache Camel.

Workspace: https://github.com/anilsaldhana/fuse/tree/master/modules/camel
Quickstart: 
https://github.com/anilsaldhana/picketlink-quickstarts-1/tree/master/picketlink-camel-security

It is working but I need to do cleanup.

On 03/27/2014 06:02 PM, Shane Bryzak wrote:
> We still have a few remaining issues to iron out which Pedro is
> currently working on, but I think this would be an excellent use case
> for the Permissions API.  I'm happy to assist in any way I can.
>
> On 28/03/14 02:54, Anil Saldhana wrote:
>> Hi all,
>>      if you look at the Dashbuilder project codebase. They have a
>> Permission implementation at
>> https://github.com/droolsjbpm/dashboard-builder/blob/master/modules/dashboard-security/src/main/java/org/jboss/dashboard/security/PermissionManager.java
>>
>> We need to get them to migrate to PicketLink Permission Implementation.
>>
>> More info on the Dashbuilder project: http://www.dashbuilder.org
>>
>> Regards,
>> Anil

From Anil.Saldhana at redhat.com  Thu Mar 27 19:57:53 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 27 Mar 2014 18:57:53 -0500
Subject: [security-dev] Dashbuilder project - permission implementation
In-Reply-To: <5334B914.1050309@redhat.com>
References: <533457CA.1010301@redhat.com> <5334ADF5.9020402@redhat.com>
	<5334B914.1050309@redhat.com>
Message-ID: <5334BB01.7080009@redhat.com>

Shane - I used the PL IDM Drools workspace as guidance for the first phase.

On 03/27/2014 06:49 PM, Anil Saldhana wrote:
> I agree Shane. As we write more demo apps/quickstarts and community
> feedback, we can iron out the Permission implementation.
>
> I have used the Permission implementation (with Drools) to create some
> integration code for Apache Camel.
>
> Workspace: https://github.com/anilsaldhana/fuse/tree/master/modules/camel
> Quickstart:
> https://github.com/anilsaldhana/picketlink-quickstarts-1/tree/master/picketlink-camel-security
>
> It is working but I need to do cleanup.
>
> On 03/27/2014 06:02 PM, Shane Bryzak wrote:
>> We still have a few remaining issues to iron out which Pedro is
>> currently working on, but I think this would be an excellent use case
>> for the Permissions API.  I'm happy to assist in any way I can.
>>
>> On 28/03/14 02:54, Anil Saldhana wrote:
>>> Hi all,
>>>       if you look at the Dashbuilder project codebase. They have a
>>> Permission implementation at
>>> https://github.com/droolsjbpm/dashboard-builder/blob/master/modules/dashboard-security/src/main/java/org/jboss/dashboard/security/PermissionManager.java
>>>
>>> We need to get them to migrate to PicketLink Permission Implementation.
>>>
>>> More info on the Dashbuilder project: http://www.dashbuilder.org
>>>
>>> Regards,
>>> Anil
>>>

From Anil.Saldhana at redhat.com  Fri Mar 28 13:29:35 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 28 Mar 2014 12:29:35 -0500
Subject: [security-dev] Discussion on OAuth and Enterprise Federation
Message-ID: <5335B17F.1050405@redhat.com>

There is an interesting thread on the IETF OAuth mailing list.
http://www.ietf.org/mail-archive/web/oauth/current/msg12552.html

FYI.

From sdouglas at redhat.com  Sun Mar 30 20:21:40 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 31 Mar 2014 11:21:40 +1100
Subject: [security-dev] Picketbox Authenticating with no principal
Message-ID: <5338B514.7070104@redhat.com>

Hi,

I have a question about Picketbox, and how I can setup a security 
context when I don't have a real credential for an account.

Basically my use case is an apache server in front of Undertow, where 
the apache server performs the authentication and just forwards the 
authenticated principal to Undertow. From an Undertow point of view
it is easy to setup that principal as the current user, however I have 
no way to then setup the Picketbox SecurityContext object, as it appears 
that the only way to do this is with a credential.

The only way I can think of that maybe we can use a custom login module, 
that does not require a credential?

Apparently this used to work, however I have not been able to find a 
working config anywhere, and I can't see any LoginModule implementation 
in the source that look like they would do this, so I am not really sure 
how to best approach this.

Stuart

From Anil.Saldhana at redhat.com  Mon Mar 31 10:25:34 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 31 Mar 2014 09:25:34 -0500
Subject: [security-dev] Picketbox Authenticating with no principal
In-Reply-To: <5338B514.7070104@redhat.com>
References: <5338B514.7070104@redhat.com>
Message-ID: <53397ADE.10106@redhat.com>

On 03/30/2014 07:21 PM, Stuart Douglas wrote:
> Hi,
>
> I have a question about Picketbox, and how I can setup a security
> context when I don't have a real credential for an account.
>
> Basically my use case is an apache server in front of Undertow, where
> the apache server performs the authentication and just forwards the
> authenticated principal to Undertow. From an Undertow point of view
> it is easy to setup that principal as the current user, however I have
> no way to then setup the Picketbox SecurityContext object, as it appears
> that the only way to do this is with a credential.
You can create a security context directly and set it on the 
SecurityContextAssociation.
You should not authenticate via PicketBox in this case.

You will need to authorize the web resources. This implies you will need 
to get the roles
for the principal in question.

Stefan can guide more.

> The only way I can think of that maybe we can use a custom login module,
> that does not require a credential?
>
> Apparently this used to work, however I have not been able to find a
> working config anywhere, and I can't see any LoginModule implementation
> in the source that look like they would do this, so I am not really sure
> how to best approach this.
>
> Stuart

From sbryzak at redhat.com  Mon Mar 31 21:29:40 2014
From: sbryzak at redhat.com (Shane Bryzak)
Date: Tue, 01 Apr 2014 11:29:40 +1000
Subject: [security-dev] Security Interceptors in Java EE8
Message-ID: <533A1684.4070704@redhat.com>

Looks like security interceptors was a popular feature request for Java 
EE8.  Something we should probably get involved with I think?

https://blogs.oracle.com/ldemichiel/entry/results_from_the_java_ee

From psilva at redhat.com  Mon Mar 31 22:57:42 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 31 Mar 2014 22:57:42 -0400 (EDT)
Subject: [security-dev] [PLINK-400] - Stateless Nature of the Identity Bean
In-Reply-To: <1751845618.5598079.1396321013176.JavaMail.zimbra@redhat.com>
Message-ID: <367285324.5598398.1396321062597.JavaMail.zimbra@redhat.com>

Hi All,

    Shane and I had a discussion today about PLINK-400 [1]. Which is basically about adding a stateless behavior to the Identity bean.

    Today the Identity bean is session scoped, which implies that an authenticated user has a corresponding session on the server. That is fine when you're using JSF as view technology and the JESSIONID cookie is used to track user session. Or even using HTML5 and JS from a browser. The point here is that you don't need to send anything special in order to know that a specific request came from an previously authenticated user. The cookie is always sent to and from the server.

    Recently, after some discussions about making PL even more suitable for mobile, we decided to add a stateless behavior to the Identity bean. Basically, instead of creating a session on the server for each authenticated user, we don't store anything. Every data consumed and produced during the authentication process is destroyed once the request is finished. This is a very important requirement when you don't want to consume server resources with users sessions, specially if you're writing a RESTful API. Another example is Anil's work to integrate Apache Camel with PL.

    Usually, those use cases are based on a token which is issued after a successful authentication. Subsequent calls to protected services will then require the token to be validated in order to know if the request is from an authenticated user or not. Or even check if the token is still valid, etc.

    We're pretty sure about adding this stateless nature to the Identity bean. But we would like to know from you if we should also support both "natures" from the same application. In other words, if we should allow the same application to use both stateless and stateful versions of the Identity bean. The use case that may justify that is when your services could support both JSF and HTML5 clients, where the latter do not use the JSESSIONID to track user session but a specific token.

    Any thoughts ?

[1] https://issues.jboss.org/browse/PLINK-400

Regards.
Pedro Igor