[PicketLink IDM] - Timed Release Version - 3.0.0-2013Jan22
by Pedro Igor Silva
Hi All,
Today, we released a new timed version for the PicketLink IDM project. The documentation and quickstarts are being elaborated, but you can always check the test cases for a lot of usage examples.
<dependency>
<groupId>org.picketlink</groupId>
<artifactId>picketlink-idm-impl</artifactId>
<version>3.0.0-2013Jan22</version>
</dependency>
The code bellow shows how to quick start using the file-based store:
// initialization code
IdentityConfiguration config = new IdentityConfiguration();
config.addStoreConfiguration(new FileIdentityStoreConfiguration());
IdentityManager identityManager = new DefaultIdentityManager();
identityManager.bootstrap(config, new DefaultIdentityStoreInvocationContextFactory());
// let's create some users, roles and groups.
User user = new SimpleUser("someUser");
user.setAttribute(new Attribute<String>("someAttribute", "someValue"));
identityManager.add(user);
Role role = new SimpleRole("someRole");
identityManager.add(role);
Group group = new SimpleGroup("someGroup");
identityManager.add(group);
// let's create some relationships
identityManager.grantRole(user, role);
identityManager.addToGroup(user, group);
identityManager.grantGroupRole(user, role, group);
This is the first version that supports all major features, including: (for the JPA and File identity stores, only)
- Identity Types Management (Common functionality for User, Group and Roles)
- Create, Update and Remove
- Custom attributes
- Queries can be done using all suported parameters. Including custom attributes.
- Organization by Partition (Realm or Tiers)
- Relationship
- Create, Update and Remove
- Custom attributes
- Queries can be done using all supported parameters. Including custom attributes.
- Supports custom Relationships (user-defined)
- Provided Relationships:
- Grant (User x Roles: User has Role )
- GroupRole (User x Group x Role: User has Role as member of Group)
- GroupMembership (User x Group: User is member of Group)
- Credential
- Password
- Digest
- Certificate
- Credential expiration
- Partition
- Create and Remove Realm
- Create and Remove Partition
- Contextualized IdentityManager for Partition (forRealm and forTier methods)
- Query Identity Types by Partition
- Considering all requirements for Realm and Tiers (*Check with Shane*)
- Query Support
- Pagination and result count
Any feedback would be appreciated.
Regards.
Pedro Igor
11 years, 3 months
OAuth Provider Web Application on OpenShift
by Anil Saldhana
NOTE: the following does not use any OAuth Server implementation (no
Auth Tokens issued etc).
I just want to give you a glimpse at the PicketLink OAuth Provider web
application.
Uses: PicketLink 3.0 (IDM and Extensions), Aerogear JS, Twitter
Bootstrap, RESTEasy and AS7. Uses PL IDM as of this morning.
http://todo-anilsaldhana.rhcloud.com/picketlink-oauth-provider/jsp/picket...
You can register an account. Then log in. You can then register oauth
applications. If the name is already registered, it will throw a pop up
saying "Application is already registered". So choose some other name.
This is not a production application. Just take it for a spin.
Application restarts will lose all data. :)
I am sure there are tons of issues, broken functionality.
11 years, 3 months
My OAuth2, Central Authz, and Distributed SSO work
by Bill Burke
A week or two so before Christmas, I decided to refocus my OAuth work so
that I could support *existing* JBoss web applications. I'm about a
week or two away from releasing something. I just need to do some final
minor feature work, test it a little bit more, and write some documentation.
*NOTE* All this works with existing JBoss web applications and security
domain infrastructure.
FEATURE 1: TRADITIONAL OAUTH
You can take any existing web app and turn it into an OAuth2 provider.
Currently, it must be using servlet FORM authentication and a jboss
security domain. ALl that is required additionally is adding a valve to
jboss-web.xml, generating a realm key pain in a keystore, and putting a
small json configuration file in your WAR's classpath. Once you've done
this, your existing web app can generate access tokens and
*additionally* do bearer token auth. Client apps, just need to follow
the OAuth2 client protocol to obtain their access tokens. And do
client-side OAuth2 bearer token authentication to access the web app.
FEATURE 2: CENTRALIZED AUTHZ and Distributed SSO
* Turn any existing user/password/roles JBoss Security Domain into a
remote, centralized, authentication and authorization server. It is as
simple as creating a small WAR that is FORM auth enabled, setting a
particular jboss-web valve, and defining a simple json configuration file.
* Next, you can take any existing web app that uses FORM auth, and point
it to this central server. The plugin will do the correct browser
redirects via OAuth2 protocol to the central server. Identity and role
mappings are transferred via the access token.
* This is authentication and authorization! user auth and role mappings!
* It supports Distributed SSO. Once you've logged into the central
authentication server, you are logged into any application configured to
accept authentication/authorization from the central server.
* It supports Distributed Log Out. So, you can log out of all web
applications
* Central server has a small admin interface that allows admins to
logout a specific user (or all users) on all secured web applications.
You can also set up bearer token policies like: don't accept tokens
created before a certain date.
* Bearer tokens are generated for each browser login.
* Tokens are propagated and can be access in business logic via a
request attribute, or in JAX-RS land, the @Context annotation. You can
then use this token to access other HTTP-based services on your network.
This allows your web application to talk securely with a network of
web services.
This all works by defining a simple OAuth2 Bearer token format and using
OAuth2 protocols to obtain and distribute these tokens. My format is a
small extension to JSON Web Token that has role-mapping information. It
is signed and verified using PKI.
I have plans to extend this to work with BASIC and CLIENT_CERT servlet
authentication.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 3 months
[PicketLink IDM] - File-based Identity Store
by Pedro Igor Silva
Hi All,
Would like to know your opnion about how we're storing identity information using the File-based Identity Store and discuss possible alternatives.
Just for background, the motivation behind the file-based store is to provide a fast, ready-to-use and simple store, ideally for test and development scenarios/environments. The configuration is minimal and requires the file system.
Today we're basically serializing objects (JDK Serialization API) and storing them into files. The layout is quite simple:
/tmp/pl-idm/:
total 4
drwxrwxr-x. 2 pedroigor pedroigor 140 Jan 18 15:20 65d62693-953c-43a6-ac43-4b655174bbb4 ----> Each Partitions has its own directory
-rw-rw-r--. 1 pedroigor pedroigor 554 Jan 18 15:20 pl-idm-partitions.db ----> Serialized data for partitions
-rw-rw-r--. 1 pedroigor pedroigor 0 Jan 18 15:20 pl-idm-relationships.db ----> Serialized data for Relationships
/tmp/pl-idm/65d62693-953c-43a6-ac43-4b655174bbb4: ----> Partition directory.
total 8
-rw-rw-r--. 1 pedroigor pedroigor 789 Jan 18 15:20 pl-idm-agents.db ----> Serialized data for Agents
-rw-rw-r--. 1 pedroigor pedroigor 1134 Jan 18 15:20 pl-idm-credentials.db ----> Serialized data for Credentials
-rw-rw-r--. 1 pedroigor pedroigor 0 Jan 18 15:20 pl-idm-groups.db ----> Serialized data for Groups
-rw-rw-r--. 1 pedroigor pedroigor 0 Jan 18 15:20 pl-idm-roles.db ----> Serialized data for Roles
Serialization provides us a fast way to store data, but I have some concerns that I want to share:
- As we're serializing objects, we may have to ensure compatibility with prior versions. I think Version Control is a option here (btw, Stuart Douglas gave me some tips about that).
- Is better to use JBoss Marshalling instead of using the JDK Serialization API directly ? Mainly considering the JBoss ecosystem ?
- Is there a better format to store data ? Such as XML ...
- I had some discussions with Shane about using Infinispan. We agreed that the IDM cache will be ISPN-based, that is fine. But maybe a ISPN-based store can fits well too. ISPN allows to store data using different CacheStore implementations, transaction support, indexing, distributable or local storage, etc.
Wdyt ?
Regards,
Pedro Igor
11 years, 3 months
Fwd: security: why creating thg from scratch?
by Jason Porter
Thought if forward this one on to make sure we have it covered.
Begin forwarded message:
> From: Glh <gsouzeau(a)gmail.com>
> Date: January 15, 2013, 3:50:32 MST
> To: deltaspike-dev(a)incubator.apache.org
> Subject: Re: security: why creating thg from scratch?
> Reply-To: deltaspike-dev(a)incubator.apache.org
>
> Dear all,
>
> I start a JEE6 project (CDI/JPA/JSF) in a few months and security is a
> problem. The 3 main frameworks handling security are (sorry if i miss one):
>
> *- Spring Security:* not a good idea for a CDI-oriented architecture.
> *- Apache Shiro:* very interesting but doesn't support multi-stage
> authentication and need to be "POCed" because rather "exotic" (different
> identity model, not based on JAAS). I lack of time to perform such a POC.
> *- Seam Security:* has no future, lack of documentation.
>
> So if we consider that delta-spike security is the future but not available
> and not mature enough before a (too) long time; what should we do?
>
> I'm under the impression that you pick the best of several security
> frameworks and add some features of your own so how can we choose a security
> framework that will not imply a costly refactoring when delta spike will be
> available?
> I found some answers along this forum (and related-jiras such as "Discuss
> Security Module"; yet we need a clear path:
>
> 1) please, what will exactly be the deltaspike security module?
> 2) which existing security framework is the closest to the target?
> 3) which one will imply the least refactoring?
>
> If the answer is accurate/clear, it would be useful to highlight it: I think
> a lot of architects are in the same trouble than me.
>
> I'm not yet very confortable with Apache process so please forgive me if I
> ask questions that have already been answered somewhere.
>
> Regards.
> Glh
>
> P.S: I don't have the security requirements yet, I just know that
> multi-authentication could be required.
>
>
>
> --
> View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/secu...
> Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.
11 years, 3 months
PicketLink Extensions Workspace
by Anil Saldhana
Hi all,
a typical EE application has the use of CDI, Ajax and Jax-RS.
Given this, there are some standard Jax-rs services, apps require such as:
a) Login Services
b) Logout Services
Toward this, I created a workspace called "PicketLink Extensions" where
we can place in code that does not belong in the main PicketLink
workspace or is in some sort of transient flux.
https://github.com/anilsaldhana/picketlink-extensions
Two apps that I know can use this workspace are:
a) Aerogear TODO.
b) PicketLink OAuth provider.
I merged the PicketBox CDI workspace into the PL extensions workspace.
It allows applications to bring in optionally the extensions libraries
when they desire some functionality not provided by the main PL libraries.
Once I finish the OAuth provider webapp in the next few days, this
extensions workspace will look a lot saner.
Regards,
Anil
11 years, 3 months
PicketBox in Maven Central
by Darran Lofthouse
For a while I have been meaning to get JBoss Negotiation into Maven
Central so that I can move the toolkit from the project and into the
quick starts and for the quick starts they don't want dependencies on
our internal repos.
Within JBoss Negotiation I have a couple of PicketBox dependencies - is
there any possibility that these could be synced to Maven Central?
Regards,
Darran Lofthouse.
11 years, 3 months
Password Expiration in IDM
by Anil Saldhana
Shane/Pedro,
I changed the Password Expiration to a null date for the api when the
developer wants infinite expiry passwords. One IDM test was choking.
For now, I have set the password expiry to 1500 years if the developer
wants infinite expiring passwords.
Can you guys take a look? We need better handling when password expiry
holds a null date.
Regards,
Anil
11 years, 3 months
