PTO 12 Dec - 1 Jan
by Shane Bryzak
Hi all,
I'll be on PTO during the dates in $SUBJECT, however I'll still be
checking e-mails daily and will likely still be doing some IDM-related
work in the evenings.
Thanks,
Shane
11 years, 4 months
char[] argument is weak
by Bill Burke
Representing passwords as char[] is a weak argument. Manny of these
char[] arrays are going to have to stay in memory in some form usually
anyways. For example, a browser app may not keep a password in memory,
but it sure as hell will keep a session cookie in memory which is just
as big of a security hole. Passwords used to continually access the
same resources (DB connections, etc.) also have to remain in memory
unless you want to hit persistent storage each and every time. The
mechanisms to obtain a password from a user are often already String
based. Plus, there's no guarantee a memory swap isn't going to happen
when the password char[] is in memory anyways. Finally, if you're
running a secure system on an insecure box then you deserve your fate.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 4 months
IDM: LDAP Custom Attributes
by Anil Saldhana
Pedro,
we had discussions on performance associated in querying custom
attributes in the LDAP implementation. I realized that since we will
have an identity cache operating in the IDM layer. The cache needs to
have LRU entries (or whatever policy that gets configured) thus avoiding
round trips to the Identity Store.
Bolek had opined about the use of LDAP entry change notifications to
update the IDM cache. This is when the admin may have used some form of
LDAP browser to update the entries or update happens via software not
controlled by IDM.
Regards,
Anil
11 years, 4 months
Credentials API redesign
by Shane Bryzak
Hey guys,
I've completed the first round of redesigns for the credentials API
based on the feedback provided by Darran and others. It might require
some minimal tweaking to address a couple of minor edge cases, however
at this point in time I'd like to run through the basic design to see
what you guys think. Up front I must say that it's more complex than I
had hoped, however after analysing all the use cases I feel that the
complexity is a necessity for providing a truly robust, extensible API.
To try and present this in a logical manner, I'm going to describe the
credentials API in terms of the chronological order of events during the
authentication process. To start with, let's take a look at the
LoginCredentials interface:
public interface LoginCredentials {
void invalidate();
}
Implementations of this interface are intended to contain the state
provided by the user in order to carry out authentication. While the
Credential interface is designed to represent an atomic credential value
(such as a password, certificate, or biometric data such as a
fingerprint), LoginCredentials is designed to encapsulate the credential
value with additional state required by the authentication process.
Let's take a look at an implementation supporting the most common form
of credentials, a username and password:
public class UsernamePasswordCredentials implements LoginCredentials {
private String username;
private PasswordCredential password;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public PasswordCredential getPassword() {
return password;
}
public void setPassword(PasswordCredential password) {
this.password = password;
}
@Override
public void invalidate() {
username = null;
password.clear();
}
}
This implementation provides the capability for setting a username
(represented as a String) and a PasswordCredential. Other
implementations are free to define whichever properties they require,
for example a CertificateCredentials class may simply contain an
X509CertificateCredential and nothing else.
Once the user provides their credentials, the LoginCredentials instance
can be passed to IdentityManager via the following method:
public interface IdentityManager {
User validateCredentials(LoginCredentials credentials);
}
To handle the actual processing of the credentials and perform whatever
business logic is required to authenticate the user, the following SPI
interface is used:
public interface CredentialHandler {
User validate(LoginCredentials credentials, IdentityStore store);
void update(User user, Credential credential, IdentityStore store);
}
Since authentication is handled differently depending on what type of
IdentityStore is being used, there will be many CredentialHandler
implementations to address each use case combination. To determine the
correct CredentialHandler implementation to use for authentication, the
IdentityManager calls CredentialHandlerFactory.getCredentialHandler(),
passing in the class of the LoginCredentials parameter and the class of
the IdentityStore parameter:
public interface CredentialHandlerFactory {
CredentialHandler getCredentialHandler(Class<? extends
LoginCredentials> credentialsClass,
Class<? extends IdentityStore> identityStoreClass);
}
This allows us to provide a separate CredentialHandler implementation
for each combination of LoginCredentials and IdentityStore. For
example, for a standard username/password authentication using
JPAIdentityStore we may have a JPAUsernamePasswordCredentialHandler that
compares a calculated hash based on the password (and possible other
values) against a pre-calculated hash stored in the database. For a
username/password authentication against LDAPIdentityStore we may have
an LDAPUsernamePasswordCredentialHandler that performs a bind operation
against the directory to ensure that the credentials supplied are
valid. As the SPI is extensible, it is also possible for developers to
provide their own CredentialHandler implementations to suit whichever
authentication process they require.
If the CredentialHandler.validate() method completes successfully, it is
expected to return a User instance to indicate that authentication was
successful. If authentication is unsuccessful (or possibly requires
multiple steps) then it's up to the caller and implementation to cater
for this, most likely by providing additional state within the
LoginCredentials implementation.
To sidetrack for a moment, the CredentialHandlerFactory is configured as
part of the IdentityConfiguration which is passed to the
IdentityManager's bootstrap method during startup:
public class IdentityConfiguration {
public CredentialHandlerFactory getCredentialHandlerFactory() {
return credentialHandlerFactory;
}
public void setCredentialHandlerFactory(CredentialHandlerFactory
factory) {
this.credentialHandlerFactory = factory;
}
}
Continuing on, the CredentialHandler is free to execute whichever
business logic is required to authenticate the provided LoginCredentials
value. It has direct access to the IdentityStore instance, in which the
previous credential management methods have been replaced with the
following two new methods (side note - the CredentialHandler doesn't
*have* to use these methods, it could instead possibly invoke other
IdentityStore methods by casting the IdentityStore to the appropriate type):
public interface IdentityStore {
void storeCredential(CredentialStorage storage);
CredentialStorage retrieveCredential(Class<? extends
CredentialStorage> storageClass);
}
At present CredentialStorage is a simple SPI interface that declares a
single method:
public interface CredentialStorage {
Date getExpiryDate();
}
The reason that we have introduced a totally new interface here rather
than just use the Credential interface, is that credential information
stored by the IdentityStore is often different to the credential
information provided by a user to authenticate. For example, in
username/password authentication the user provides a plain text
password, however the data we have stored in the IdentityStore is
typically not the password itself, but a hash value (or at least I would
hope so). With that in mind, the introduction of the CredentialStorage
interface formalizes the disconnect between user-provided credential
state and stored credential state, and in turn provides a more flexible
design. This is not to say that a Credential implementation can't be
dual purpose, in fact this is fully supported thanks to
CredentialStorage essentially being a marker interface, so
X509CertificateCredential for example could easily implement both the
Credential and CredentialStorage interfaces.
To round this off with a solid example, here's what a CredentialStorage
implementation that stores a password hash might look like:
public class PasswordHash implements CredentialStorage {
private byte[] hash;
public void setHash(byte[] hash) {
this.hash = hash;
}
public byte[] getHash() {
return hash;
}
}
There's actually one more step here, and that's the metadata required by
the IdentityStore to know which state of the CredentialStorage instance
to actually store. To enable this, we have introduced the @Stored
annotation, which when added to the above example looks like this:
public class PasswordHash implements CredentialStorage {
@Stored private byte[] hash;
public void setHash(byte[] hash) {
this.hash = hash;
}
public byte[] getHash() {
return hash;
}
}
Any properties annotated with @Stored must be Serializable, to allow
storage by the IdentityStore.
One last thing that needs to be covered is the updating of credentials.
IdentityManager also provides this method which is used to update a
user's credentials:
public interface IdentityManager {
void updateCredential(User user, Credential credential);
}
Like credential validation, a CredentialHandler is looked up the same
way and its update() method is invoked with the User, Credential and
IdentityStore parameters. It is up to the CredentialHandler
implementation to create the appropriate CredentialStorage instances (or
perform whichever other business logic that might be required) to
persist to the backend IdentityStore.
That pretty much covers everything. I think this design in essences
addresses all of the use cases discussed so far, and should be
relatively future-proof. Sorry again for another wall of text, but I'm
looking forward to hearing feedback on this. There's still quite a lot
of work to do in this area on the implementation side of things (such as
decoupling the existing credential validation code from the
IdentityStore implementations and implementing it as CredentialHandlers)
but we'll get to that once everyone has a chance to review this new design.
Thanks,
Shane
11 years, 5 months
PicketLink Authentication Discussions
by Anil Saldhana
Hi All,
I think we should continue the other thread on "Credential API design".
It just shows how we all agree to disagree. :)
I suggest the following:
a) IDM Subsystem should concentrate on Identity constructs
(User,Role,Group,Attribute,Application,Tier etc) and stores (db,ldap etc).
b) Lets move authentication and credential handling to a layer above
IDM. Maybe PL Authentication subsystem. We did do some implementation
in PicketBox5 that we used password credential, otp, social, kerberos
etc etc with one authentication logic. We can take a look at that.
c) Lets document all the credential types and usecases we plan to
support. I know we want to do combined authentication, silent
authentication, digest, salt/hash, multiple channels etc etc.
c) is going to be the most contentious piece of the puzzle that the
industry is still not solved. Given that authentication semantics
compared to fine grained authorization are finite, we should have solved
this easily.
Regards,
Anil
11 years, 5 months
Ajax Session Management discussion (Security Related)
by Anil Saldhana
Hi All,
I want to learn a bit on ajax session management. There are probably
things I do not know and may learn from the Richfaces/Aerogear and other
folks. :)
With the classic servlet based web apps, the sessions are managed by the
servlet container. So when the session times out on the server, a
secured web app may just return the login page. Without responsive web
apps (no use of ajax for example), this works fine.
When an app makes ajax calls to the server, the session may have expired
or invalidated. In this case, the server may send a response (such as a
login page) that is different from what the ajax call was expecting and
the flow is disrupted to yield a bad user experience.
I guess we need to have mechanisms to identify ajax calls (header
"X-Requested-With") and determine if the session has timed out/expired
and send back an appropriate http code so that the browser app can
handle this use case properly.
If Ajax calls are involved, I would guess the web app security is
probably not container managed (via web.xml/security annotations). We
will need the following in container bindings project or something like
that:
a) A servlet filter for ajaxified web app with its own web security.
b) Updated Tomcat Authenticators for the case when container security is
used and the web app wants to have ajax calls too.
Regards,
Anil
11 years, 5 months
PicketLink 3 IDM - Information Contained Within a User
by Darran Lofthouse
Keeping in mind that a user could represent either a human or non-human
agent is it really correct to assume that all users have a first name, a
last name and an e-mail address?
Even for human users whilst it is likely they would have all three of
these does it make sense to assume they always will? I am just thinking
could it make more sense to maybe have an 'Account' interface above
'User' to allow for accounts that have no relationship to humans?
Regards,
Darran Lofthouse.
11 years, 5 months
oauth scope effect on data model
by Bill Burke
Hey all,
Looking at and implementing OAuth use cases, I've realized there's an
additional piece of metadata that may not fit into the current identity
model.
In OAuth a client can ask for specific permissions to access a protected
resource on behalf of a user. This is called the "scope". Clients are
registered with the auth server. You probably want to limit the "scope"
a client is allowed to ask for. For example, you probably don't want to
allow clients to ask for "admin" privileges as a user may accidently
grant them those permissions.
So, the identity model changes. Scope looks a lot like a role mapping,
but it isn't a role mapping. It is a set of roles one user is allowed
to grant to another. Do you think this fits in the current model?
Thanks,
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 5 months
Release schedule
by Pete Muir
I've seen various messages about the release schedule, but it would be really helpful for me to have an overview page, so I can understand what we are aiming at...
Including dates, *high level* roadmap etc.
11 years, 5 months
