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.
13 years
checkstyle.xml in PicketLink workspace
by Anil Saldhana
Hi All,
wondering if we can enforce checkstyle across all the modules in the
PL workspace? Currently just one or two modules are enforcing.
I know some of you have philosophical indifference to checkstyle. I
would like to propose unformity across the modules in terms of code
structure.
Regards,
Anil
13 years
common module in picketlink
by Marek Posolda
I mentioned yesterday that it may be good to have something like
separate "common" module, which will contain some stuff and
functionalities, which may be needed across all other picketlink modules.
Example of such things could be:
- Class StringUtil from federation module (Some stuff in this class is
specific to federation, but some common methods like
StringUtil.isNotNull, StringUtil.getSystemPropertyAsString etc. are
useful in other modules as well)
- Probably some other util classes in federation
- Some parts of logging
- Reflection and properties helper classes from IDM module
- Base64 util class (Currently we have same class forked two times in
picketlink project. Once in "federation" module and once in "idm" module)
- Probably some more...
wdyt?
Marek
13 years
IDM: Support for XML configuration
by Marek Posolda
Hi,
I am seeing in IDM testsuites that currently there is support only for
programmatic IDM configuration. Is there some plan to build IDM
IdentityManager also from XML configuration? Maybe I can start on it if
nobody else is working on it?
I am adding some example configuration file into attachment with some
proposal how it could possibly looks like. Note that nothing is final
and some things are still missing (especially configuration of realms,
tiers etc.)
What do you think?
Thanks,
Marek
13 years
Multi Stage Authentication
by Anil Saldhana
Hi All,
I have been thinking about the multi stage authentication process
that Bill has been mentioning. Basically, the discussions have been
confusing between multi mechanism authentication vs multi stage
authentication.
In multi mechanism authentication, the framework needs to support
multiple authentication mechanisms such as Credential, X509, OTP, Custom
etc, given different entry points into the application -> browser,
mobile, rest etc.
In multi stage authentication, the framework needs to provide hooks to
define the stages in a complex authentication process for high risk
applications such as banking, credit etc.
Some of the stages are highlighted here:
credential ------> Knowledge based authentication (Questions and
Answers) --------------->Index Page
credential -------> KBA ------------> Mobile SMS Code
-------------> Money Transfer Page
credential ------> OTP -----------> Index Page
credential ----------> Index Page ---------> OTP ----------> Money
Transfer Page
Generically:
stage1 -------> stage2 -------------> Resource
So if there is an application developer who wishes to incorporate stages
into the authentication process, he can use the IDM underneath to hold
the state of the stages as well as will need hooks into defining the
authentication type for each stage.
Thoughts?
Regards,
Anil
13 years
