Picketlink v1.0.2 is released

Project Page: PicketLink

If you are looking for SAMLv2, WS-Trust and OpenID support for your web applications, then PicketLink is the destination. PicketLink has deeper bindings with JBoss Application Server and Apache Tomcat. But we do offer support for any generic web container.

PicketLink is also the ideal choice for Single Sign On for Seam Applications.

Get it here.

Please stay tuned for more information on this release.

======================

Release Notes for PicketLink Federated Identity
Includes versions: PLFED_1.0.2

** Feature Request
* [ PLFED-5 ] Seam authentication filter: add OpenID support

** Bug
* [ PLFED-19 ] FileBasedMetadataConfigurationStore.loadTrustedProviders keeps trustedFile locked for some indeterminate period
* [ PLFED-25 ] FileBasedMetadataConfigurationStore trusted providers file has improper extension
* [ PLFED-13 ] HTTP_Redirect binding: query string parameter SigAlg is not filled properly

** Task
* [ PLFED-7 ] PicketLink STS - parse the OnBehalfOf contents of WS-Trust request

** Release
* [ PLFED-44 ] Release PL Fed 1.0,2
=====================================

Some new exciting features for Seam and PicketLink integration from Marcel:

http://community.jboss.org/wiki/HowtoaddSAMLandOpenIDauthenticationtoyourSeamapplication


http://community.jboss.org/wiki/ExternalauthenticationexampleusingSSOCircle


http://community.jboss.org/wiki/ExternalauthenticationexampleusingOpenSSO


PicketLink's Seam Module V1.0.2: many new features!

Note from Marcel: It's a big leap forward. The sample app is now a proof that the Seam module of PicketLink integrates well with external SAML and OpenID identity providers. And installing it in a JBoss AS 5.1 server is as simple as deploying the war file. I'm looking forward to the experiences of the community when using it.

Documentation:

http://community.jboss.org/en/picketlink?view=documents

If you are looking for a cheat sheet to run SAML on JBoss AS5.1, take this cheatsheet.

Note:
1. All software has bugs. If not, they are lying.
2. Feedback is greatly appreciated.

Tip: Interpretation of missing EJB Method Permissions in JBoss

The EJB 2.1 specs on this case says:

"It is possible that some methods are not assigned to any security roles nor contained in the exclude-list element. In this case, it is the responsibility of the Deployer to assign method permissions for all of the unspecified methods, either by assigning them to security roles, or by marking them as unchecked."

What this basically means is that if you have not specifically assigned method permissions or made them "unchecked", then it is left to the vendor's interpretation.

Default interpretation of missing method permissions in JBoss is "excluded" mode.


Based on JBAS-2471, we have incorporated a jboss.xml setting that will provide the appropriate interpretation of missing method permissions - whether to interpret them as "exclude" or "unchecked".

=======================================

<!-- The missing-method-permissions-excluded-mode determines the treatment
of missing method-permission mappings in the ejb-jar descriptor. The ejb 2.1
spec states: "It is possible that some methods are not assigned to any security
roles nor contained in the exclude-list element. In this case, it is the
responsibility of the Deployer to assign method permissions for all of the
unspecified methods, either by assigning them to security roles, or by marking
them as unchecked." The missing-method-permissions-excluded-mode is a boolean
that allows the deployer to globally indicate that all methods without a
method-permission element should be treated as excluded(= true and the default),
or that methods without a method-permission element should be treated as
unchecked(= false)

<missing-method-permissions-excluded-mode>true</missing-method-permissions-excluded-mode>
<missing-method-permissions-excluded-mode>false</missing-method-permissions-excluded-mode>

-->
<!ELEMENT missing-method-permissions-excluded-mode (#PCDATA)&rt;
===========================

First Case:
In the first case, if you specify:
<missing-method-permissions-excluded-mode>true</missing-method-permissions-excluded-mode>

in your jboss.xml, then all methods that do not have an associated method-permission are excluded from the deployment.

Second Case:
In the second case, if you specify:
<missing-method-permissions-excluded-mode>false</missing-method-permissions-excluded-mode>
in your jboss.xml. then all methods that do not have an associated method-permission are operating in an unchecked mode.

Reference:
1. Discussion on ejb3 interpretation of this flag. (Under investigation)
2. Default setting in standardjboss.xml

Tip: Role Mapping in JBoss Application Server v5.x

If you are interested in mapping roles at the deployment level (such as EARs, WARs, EJB Jars) to the roles deduced at the security domain level, then you should read this article: http://community.jboss.org/wiki/MappingRolesinJBossApplicationServerv5x

Note the use of org.jboss.security.mapping.providers.DeploymentRolesMappingProvider

Note: This is an additional forced interpretation of role mapping for the containers when our normal regular interpretation is deployment roles for addition into a RunAs identity.

Growing Menace of Identity Theft

The latest article in Washington Post titled "Identity thieves use sophisticated techniques to steal money" is a proof of the growing menace of Identity Theft that is plaguing the developed free world.

Once your identity is stolen, it is very very difficult for you to recover from the trauma. Based on victims' experiences (and other experiences in the comments section), we have to admit that Identity Theft is a menace and is a growing reality.

You have to know that your kids/toddlers are not safe either. Check this report on "Child Identity Theft".

Stay Safe.