Hi,
Thanks for the answer. I have now added Support for LoA in the Wishlist. I have been informed that there is a work on LoA in eduPerson so that the implementation of LoA in CAS should harmonize with this. Pål Axelsson Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Scott Battaglia Skickat: den 23 april 2008 04:05 Till: Yale CAS mailing list Ämne: Re: Ability to specify demand on Level of Assurance in the authentication request Hi, Sorry for the delayed response on this. It got lost in some emails. This seems like an interesting feature. We're currently gathering ideas for the next major version of CAS (we have a wishlist in the wiki). If you can add any details to the wishlist about this feature (maybe just copy in the whole email ;-)) that would be great. We can't make any guarantees on what will be in the next version. Just because its on the wishlist doesn't mean it will get in, but its the best place to keep track of these (or as a JIRA issue). Thanks! -Scott On Wed, Apr 2, 2008 at 3:49 PM, Pål Axelsson <[EMAIL PROTECTED]> wrote: Hi, The reason I write this mail is that some of us CAS users in Sweden has found that different application needs different assurance levels regarding the authentication handler and the user identity. For example a personalized page may just need an simple self asserted identity, a student portal need an proofed identity with a username and password login and a web page where examiner report the students results may need a onetime password (OTP) or certificate login. What we can see there is a good "industry standard" for level of assurance in the combination of OMB M-04-04 (http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf) and NIST SP800-63 (http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf). To go the technical way to say that we demand OTP for login or username/password for login due to the fact that the login technique changes via time and is a question for the CAS server not the application server. So what we want to do is to make CAS level of assurance aware and we want to hear what the rest of the CAS community has to say about this idea. And if it's feasibly to include in CAS. To use multiple CAS installations to accommodate this functionality is not a very good solution due to that than you need to install, configure and support multiple CAS installations. Furthermore the application deployers must think more than once when they configure which CAS server that should be used for the application. The solution is to add an optional parameter demandLoA to the /login credential requestor to demand a lowest combined level of assurance for the authentication. The combined level of assurance in this scenario is the lowest level of assurance of the areas registration and identity proofing, credential management and tokens used for proving identity. The other two areas in NIST level of assurance must be seen in the light of CAS itself. If the optional parameter is not available in the /login URI then a predefined level of assurance should be used. To evaluate the registration and identity proofing level of assurance CAS need to know about under what level of assurance a specific user got his electronic identity. This can be done for example via the LDAP attribute defined in FAME-PERMIS Definition of the LoA Attribute (http://www.fame-permis.org/loa.html) or predefined for all users in the configuration for CAS. To set the level of assurance for credential management I think it should be sufficient to predefine it in the configuration per identity provider that is used in the CAS installation. What authentication handler, or handlers, that is valid for each level of assurance should be defined in the configuration of CAS. The login page must be configured to handle multiple authentication handlers and present a choice of authentication handler where the combined level of assurance is equal or higher than the demanded level of assurance. Pål Axelsson, Uppsala universitet, for SWAMI* CAS Special Interest Group *Swedish Alliance for Middleware Infrastructure, SWAMI, is the organization for middleware cooperation in the Swedish higher education community. (http://www.swami.se) _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas -- -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
