On 5/17/12 9:04 AM, Marvin S. Addison wrote:
It's been a few days, does anyone have questions we can answer or
otherwise help move this along?
I've reviewed the whitepaper and I believe there are some interesting
intersections between your work and CAS features of general interest
to the community. I'll generalize the features as I see them:
Thanks. I ran your questions past the rest of the team. From your
questions we can tell you've really taken the time to understand our
approach and we really appreciate that.
- Per-service dynamic attribute release with support for principal
and attribute transformation.
- Multifactor authentication.
API support for the latter is on the roadmap for 4.0, and ideally your
work would leverage that API. It's not clear to me how or whether a
service can request a particular authentication credential or
attribute set from CAS, but that's an interesting problem for which we
do not yet have a solution. If you've implemented that feature, I'd
appreciate an outline of your solution.
We want to free services in our deployments from caring about the
details of attribute sources, authentication, and so on. Specifically,
we are not trying to solve the problem of allowing a service to request
a particular authentication credential or attribute set from CAS. For
those reasons we don't have a solution for this.
Your existing support for supporting authentication by what are
effectively interchangeable credentials is a convenience to users, but
it appears to come at the cost -of security. In particular,
credentials are not interchangeable with respect to level of identity
assurance. I believe releasing attributes bound to a credential of
higher LOA (e.g. X.509 cert) for an SSO session started with a
credential of lower LOA (e.g. user/pass) results in a spurious
attribute assertion.
It's certainly the case that with this extension an administrator could
allow a user to link lower-loa credentials to higher-loa attributes.
This might or might not be desirable. In our view this comes down to a
policy decision on the part of the administrator deploying the system,
and it might be appropriate in some environments and not in others. In
the environments we have been targeting so far, this has been exactly
what was needed.
Even if administrators link the credentials, they can still configure
which attributes get released under which circumstances, so higher-loa
attributes don't haveto be released. Again, it's completely up to the
administrator.
We feel that security and usability aren't always complete trade-offs,
that ease of use can improve security if users are implementing
workarounds. Therefore, we feel that if the administrator does not want
to allow the drop in LOA, then there is a risk that the users will
employ workarounds that aren't good either (e.g. email themselves their
X.509 certs).
Another point of consideration here is the linking step. By requiring
the user to authenticate, during linking, with each credential we are
assured the user at least has access to those attributes, even if the
user wants to use a weaker LOA credential in the future to access them.
I'm not aware of any research or literature on the matter, but if
anyone is aware I'd appreciate a pointer to a reference; alternatively
an informed confirmation or rebuttal would be helpful.
I'm eager to review the details of how you've implemented dynamic
attribute release, but the structure of the source on github is a
roadblock. One simple change would facilitate review: make the root
directory a parent project of the submodules. The CAS server codebase
is structured this way and it may provide a helpful reference. Once
that change is made, I'll import the project into my IDE and do a
thoughtful code review.
Please see the updated source on github. We've made the requested
change, but if you find anything else please let me know.
Thanks,
Jason
--
You are currently subscribed to cas-dev@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
