PicketLink 3 - IDM API - Credential Management
by Darran Lofthouse
I am currently looking into using the IDM API as I am authenticating
some HTTP requests and I am running into a couple of questions, the
aspect of the API I am currently looking at is: -
// Credential management
boolean validateCredential(User user, Credential credential);
void updateCredential(User user, Credential credential);
Correct me if I am wrong as it is the foundation of what I am thinking
about but I am seeing the 'validateCredential' as the method to call to
validate that the Credential supplied by the user is valid so that we
can verify the user is who they claim to be.
There is quite a lot below so it may make sense to subsequently break
these out into their own discussions.
* Userless Validation *
As mentioned on the other thread something I would find really useful is
something along the lines of: -
User validateCredential(Credential credential);
This would be for situations where there is a direct mapping from the
Credential to the user it relates to, my main example being a
X509Certificate.
I am looking at this from the perspective of - The IDM is already
managing the association of User to Certificate so to call
validateCredential I would see it as better that the calling code is not
forced to map it to the user first.
* Multiple Credentials *
The validateCredential method potentially allows many different types of
Credential to be used - however the updateCredential method seems to
apply a 1:1 mapping of User and Credential.
I can see situations where a user would have multiple Credentials, an
immediate example being both a Password and a X509Certificate.
* Ambiguous Meaning to Credentials *
This is just something I am not as clear on how the two relate and think
it has the potential to be confusing using the same Credential interface
for validation and for association with the user.
For Credentials such as the PasswordCredential and
X509CertificateCredential these do make sense to both be validated and
associated.
But then there are Credentials like the DigestCredential which only make
sense to be validated but not associated.
* Multiple Representations of Same Credential *
Another requirement I may have is storing multiple representations of
the same Credential against the same user - this is just thinking out
loud at the moment so not sure if this would be a responsibility of the
IdentityStore.
The situation here is that the user has one password but we want to
support two different hashes with Digest authentication - if we want to
choose to pre-hash the password with the username and realm we would
need to do that once per type of hash supported.
The benefit of pre-hashing in this way is that if the user has used the
same password but for a different realm someone gaining access to the
hashed form does not necessarily get access to all of that users accounts.
* Access To The Credential *
The next issue is where access to the credential is required or at the
very least something is needed to be generated from the credential -
this is used in client/server scenarios where the server also proves to
the client that it knows the users password.
Keeping the Credential so that it can not be retrieved from the IDM is
good but it does open up the need to be able to generate some response
values within the IDM based on additional information supplied.
The example I currently have is regarding Digest authentication, I have
a need for the following two hashes to be generated: -
"username : realm : password"
"username : realm : password : nonce : cnonce"
The first could be the pre-hashed password I mention above but the
second definitely needs generating on demand as we have both the nonce
that was generated from the server and the nonce the client has sent to
challenge the server.
Regards,
Darran Lofthouse.
11 years, 10 months
Google Hangouts :: PicketLink community
by Anil Saldhana
Hi all,
I created a Google+ community for PicketLink to enable sending hangout requests to the g+ community, rather than individuals.
Joining this g+ community is optional but suggested. :)
Regards,
Anil
11 years, 12 months
Identity Management - Yale University
by Eric Wittmann
Hey everyone. I've been lurking on this list for a little while and
also working with Kevin Conner and the JBoss Overlord team discussing
our future security requirements. During those discussions I mentioned
my experience with identity management during my stint working at Yale
University.
Kevin suggested that the information might be useful to picketlink IDM
and asked if I could put something on "paper" (not his words) and send
it to this list.
So attached you will find a simple/quick overview of some relevant
aspects of the Yale ITS IDM project. I spent a lot of time there
working in that space, so I'm happy to expand on anything in the
attached document. Of if there are any other questions I can answer
about that environment, I'm happy to do that too.
FWIW. :)
-Eric
12 years
[PicketLink IDM] - Timed Release 3.0-2012Dec14
by Pedro Igor Silva
Hi All,
Today we released a timed version for the PicketLink IDM project.
<dependency>
<groupId>org.picketlink</groupId>
<artifactId>picketlink-core-api</artifactId>
<version>3.0-2012Dec14</version>
</dependency>
<dependency>
<groupId>org.picketlink</groupId>
<artifactId>picketlink-idm-impl</artifactId>
<version>3.0-2012Dec14</version>
</dependency>
This release does not have all features implemented, yet. The following list shows what is available so far:
- User, Group and Role Management.
- Query API for User, Groups and Roles.
- Support for User-defined/custom attributes.
- Relationships between User, Group and Role (eg.: "User has Role" and "User is the Manager of Group").
All the items above are working with both JPA and LDAP Identity Stores.
For more information about the API usage, I recommend to take a look at the test cases:
- https://github.com/picketlink/picketlink/tree/v3.0-2012Dec14/idm/impl/src...
To run the tests, just use one of the provided test suites: JPAIdentityStoreTestSuite and LDAPIdentityStoreTestSuite.
Next week we'll continue to work on the missing features and review/add the test cases. The documentation is being updated as weel:
https://docs.jboss.org/author/display/PLINK/PicketLink+IDM
Best Regards.
Pedro Igor
12 years
#picketlink channel on irc
by Shane Bryzak
Hey guys,
Just a reminder that many of us hang out in the #picketlink channel on
IRC, and (lately at least) many development discussions have been going
on there especially in relation to the identity management work we've
been doing. Of course, important development decisions will always be
posted to this mailing list however I encourage anyone that's interested
to join us in IRC if you would like to contribute or simply to stay in
touch with what's going on with the PicketLink project.
Shane
12 years
input on bearer tokens and cookies
by Bill Burke
I'm looking for some input.
For the OAuth SSO protocol I'm working on, I'm thinking of storing the
bearer token within a "secure" cookie and verifying the bearer token
each HTTP request (for browser-based apps only). The upside to this is
that you can establish a stateless SSO between a set of load-balanced
servers. Downside is it takes about 1-2ms on my box to both parse and
verify the cookie. TO much overhead? Should I store the unmarshaled
token in the HTTP session instead?
Any other thoughts on bearer tokens stored in cookies?
Thanks
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
