The timing of this discussion is absolutely great! I really like hearing these ideas. At my organization we are planning to kick off a project to implement Levels of Authentication in our CAS deployment. We are planning to assign two developers to the project (I am one of the two) and it will likely be our top-priority Identity Management project. We are hoping to develop our project in such a way that the CAS community can adopt it and ideally merge it into the official CAS product. We plan to do the majority of our development work in a public fork of CAS on Github.
I think I agree with a lot of what Jerome and Marvin are saying. I'd like
to through in a few of the thoughts that I've been documenting recently in
preparation for our upcoming project.
Our LOA project hopes to address aspects of many of the
following areas:
* Multi-factor authentication (higher levels of authentication)
* Public identity providers like Facebook (lower levels of authentication)
* Password strength indication and enforcement
* Communicating authentication metadata, such as method and timestamp, to
CAS clients
* Interrupt screens to enforce password strength and other authentication
mechanisms
* Both reactive and proactive LOA enforcement
* Both client and server LOA enforcement
The reason these are all part of the same project is that they all
interact with each other, and the implementation of one aspect will likely
affect the implementation of others.
*LOA Policies*
The basic principal of Levels of Authentication to me is this: each
service can define a policy such that a user is required to have
authenticated with some specific form of credentials (or computed "level")
in order to access that resource or service. Each service can have a
unique policy that defines what it things is "secure enough."
In the general sense, policies could be defined in terms of raw
authentication metadata, such as a authentication type, timestamp,
password strength, multiple combined authentications, etc. To simplify
things, some policies can instead be defined in terms of a computed
numeric "level" that indicates the relative
strength of the authentication mechanism.
A deployer-specific algorithm would be used to convert the raw
authentication metadata into a numeric assurance level. See below for some
examples of different "types of authentication." I tend to agree with
Jerome that LOA should cover all aspects of authentication, including
things like "remember me" cookies and public identity providers (OAuth).
*Enforcement Points*
In a CAS environment, LOA policies could be enforced at various points.
1) Client enforcement (reactive): The server passes to the client
metadata describing the form of authentication that was used. This can
include a numeric "level" but should also include specific details, such
as the method of authentication, the strength of the password,
authentication chains, and an authentication timestamp. The client
determines if this authentication is adequate. If it is not adequate, the
client sends the user back to the server with some additional metadata
indicating what form(s) of authentication would be adequate. The server
then gathers these new credentials from the user, validates them, and then
reasserts a new authentication to the client. If the server has
previously gathered and validated credentials that meet the client's
requirements, then it can reassert authentication with new metadata
immediately without any user interaction.
2) Server enforcement (reactive): This works very similarly to client
enforcement, except that the authentication requirements for the
service/client are registered with the server. Therefore, the server will
not bother to generate a service ticket for the client until it confirms
that the credentials used for authentication are sufficient. This can be
used in conjunction with client enforcement to reduce redirects, or it can
be used in place of client enforcement to decrease the complexity of the
client and to centralize policy management.
3) Server enforcement (proactive): This usually applies when the LOA is
applied directly to a user instead of being applied to a service. If a
certain user has been granted a high level of access, it is good to force
them to increase the strength of their authentication methods, such as
registering a hardware token device or increasing the length of their
password, prior to their first attempt to access the sensitive resource.
(Otherwise an attacker could compromise the account while the password is
still weak, for example, and then strengthen the password to gain access
to the sensitive resource.) This probably needs to be implemented in two
ways: a) through the self-service mechanism; and 2) through interrupt
screens that force the user to upgrade the strength of his password, for
example.
Reactive enforcement depends on there being already-established strong
credentials.
Proactive enforcement is used to establish those strong credentials prior
to the user accessing the sensitive resource.
*Similarities to CAS Renew*
As Marvin pointed out, LOA enforcement is very similar to CAS's current
"renew" functionality. The "renew" parameter in CAS can be viewed as a
very small subset of LOA. In this case we have two types of credentials:
"username/password" and "TGT cookie." (Note that technically the "TGT
cookie" credential is chained to a previous "username/password"
authentication.)
The enforcement point in this case happens at the client+, which can send
the user back to the server with some metadata specifying the desired
credential. In other words, "renew=true" means "The TGT cookie isn't a
good enough credential. Please use the username/password credential
instead." The server fulfills this request and then sends the user back
with a service ticket (assertion) that the client is able to validate as a
non-cookie authentication.
+Note that when the Service Manager is used, this policy can also be
enforced at the server level by setting a checkbox on the registered
service.
*Types of Credentials*
In looking at the similarities between "renew" and "LOA", it started to
become clear that these two concepts, and many others, are very closely
related to each other. A generalized LOA mechanism should probably be
able to handle any of the following types of credentials:
* Username/Password
Metadata: Strength, Last-Changed
* Security Questions and Answers
* Facebook Login
* Twitter Login
* Google Login
* Other public identity providers
* Login via Federation to a trusted identity provider
* Code sent to SMS
* Code sent to email
* Google Authenticator or other mobile app
* Hardware token generator
* Certificate
* Current session cookie (TGT)
Metadata: Original authentication method, last-used-timestamp
* Remember-me cookie
Metadata: Original authentication method, last-used-timestamp
* Registered device identifier (This is often used
in conjunction with another form of authentication to detect when the user
is
accessing the service from a new device.)
* Temporary-use passcode that can be generated and given to help-desk
personnel for diagnosing problems.
All methods would probably include some form of common metadata, such as
timestamp. One user session might include multiple authentication events.
Some events would be chained together. For example, the TGT cookie
authentication event would be chained to whatever authentication events
were used to establish the cookie.
*Other Thoughts*
I think that CAS deployers should be able to configure how various
authentication methods map are converted into a numeric level. Each
organization probably will have different policies.
Policies need to be declarative. In other words, they can't consist of a
method that takes the metadata and returns true or false. The reason
policies need to be declarative is that when the user fails a policy, the
policy enforcement point needs to communicate the failure to the server in
such a way that the server can request additional credentials from the
user such that the next assertion will be sure to pass. The communication
from client to server needs to be able to specify acceptable forms of
authentication and authentication details (such as password strength) in
addition to possibly specify a required numeric "level."
While I think it is fine to implement this by looking at how "renew" is
implemented and extending those concepts, I would recommend defining new
aspects to the protocol instead of trying to simply extend the renew
mechanism itself. Internally, the CAS server and clients would probably
use the new LOA mechanisms to implement renew functionality, though new
implementations might even use the new LOA protocol to implement
renew-type functionality.
The SAML spec contains some provisions for passing authentication metdata
to the relying party (i.e. to the CAS client). That could work great for
clients that support the SAML ticket validation endpoint, but it might be
nice to enhance the CAS protocol's XML to include metadata too.
Sometimes it might not be good to pass all of the authentication metadata
to all clients. Some clients shouldn't be trusted with some of the
internal details of a user's authentication, since that information might
be used to form an attack against the user. Policies enforced on such
clients would have to rely on the computed numeric "level" instead of
details, but administrators could also use more flexible policies enforced
on the server without releasing the detailed authentication data to the
client.
On 8/1/12 7:30 AM, "jleleu" <lel...@gmail.com> wrote:
>Hi,
>
>Be sure I also want to avoid useless questions and endless discussions.
>However, I still have some questions before starting to write the spec.
>
>* renew mechanism
>
>I quote you : "upgrade session via new authentication if needed,
>otherwise pass through and issue a service
>access token". That's exactly what I have in mind.
>I think I understand your solution : each time an access will be granted
>(service ticket), you get the LOA from authentication and store it with
>this access, this way next time this CAS service asks for "renew", you
>will check if the current LOA is sufficient and display the login page if
>needed.
>
>renew=true means re-authentication whatever the previous authentication
>is. So if you want to stay backward compatible, you can't change this,
>you need a renew=increase_loa.
>Do you want to specify an explicit loa name by renew or just ask for
>increasing loa level ?
>
>
>* LOA definition
>
>I agree with you on LOA definition, but I definitely don't understand why
>you don't consider remember-me, IP check and OAuth authentication as LOA
>levels (I have real world use cases for them). In all cases, you have
>credentials assuming with more or less confidence who the principal is.
>Remember-me is the most specific one as it's somehow computed and not
>statically defined. But let's talk about this later.
>
>Can you point me to some docs at "InCommon Assurance program" ?
>
>I would also consider defining LOA not only by strict oder :
>4. Authenticated
>3a. IP authenticated 3b. OAuth authenticated
>2. Remembered
>1. Anonymous
>
>
>* Authentication mean
>
>You're right, there are highest LOA above username/password. By the way,
>what's VT ?
>
>The question is : what authentication mean to display when current LOA is
>not sufficient ? So far, we just have one : login page for
>username/password.
>Do we need to create a new concept : authentication mean associated to
>LOA ? Or just display the login page when LOA is not sufficient ?
>
>
>* LOA of CAS services
>
>So far, we talked about client initiated flows (asking for increasing
>LOA). But I think we can also have LOA definition in CAS service (no use
>of renew parameter).
>Does it make sense to you ? If so, I will add a second example in spec
>with LOA defined in CAS service.
>
>I think that the same mechanism applies to LOA defined in CAS service as
>if it was requested with renew parameter. If both are defined, the LOA
>requested to CAS server is the highest LOA between renew asked by client
>and supported LOA of the CAS service.
>
>Thanks for your help,
>Jérôme
>
>--
>You are currently subscribed to cas-dev@lists.jasig.org as:
>nathan.k...@ccci.org
>To unsubscribe, change settings or access archives, see
>http://www.ja-sig.org/wiki/display/JSG/cas-dev
--
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
default.xml
Description: default.xml
