Re: Accessing Service on Behalf of the User--supported in OpenId?
Thanks for the reply...some comments in-line! On Fri, Aug 15, 2008 at 6:26 AM, James Henstridge [EMAIL PROTECTED]wrote: 2008/8/15 Scott Battaglia [EMAIL PROTECTED]: snip / 1. Do you guys support accessing a service on behalf of a user. In CAS we call this proxying on behalf of the user. But essentially, if you're say, a portal, and you need to access the grades, you would retrieve a CAS proxy ticket and give it to the grades service which would resolve that to the user as well as the chain of where it came from. There are a few models that can be used for this: 1. The user goes to the grades service and requests that their data get transferred to the OpenID provider via the attribute exchange protocol. When they go to the portal site, the portal can request the data from the OP, again using attribute exchange. Of course, in this model there is no direct contact between the portal and grades service in this model, so the portal would need some way of verifying that the data it got was correct. Digital signatures are probably the answer here, but there is no standard for this yet (there was a proposal for this a while back though). This doesn't look like it would fit our model. Some of the services are purely RESTful or SOAP (and are currently designed to take CAS proxy tickets, which seem similar to OAuth...) 2. Use OAuth. The portal acquires an access token to the grades service. This involves sending the user to the grades service to authenticate (which might be done using OpenID). The portal can then use the access token to request the data directly from the grades service. This seems like a more viable solution. This is probably more of a OAuth user list question but I figure I'll check here first. It doesn't look like OAuth does attribute exchange, is that true? Or is there an extension we could use (or a standard way to add extensions). My guess is that would start to get a little weird because if there's no interaction then there is no way for a user to approve/deny attribute exchanges unless there's a central decision made about attribute releases (which may work for us, but probably doesn't work in a general case) Some of the other stuff is more related to local SSO needs than the actual protocol, but I'll ask anyway: 1. Do you support a method of determining whether someone has authenticated already (in CAS we call it gateway)? For us it relies on the fact that you always point to one CAS server, which obviously doesn't need to be true in the case of OpenId.However, in the scenario where you know there is only one authenticating server, is this possible? If you are implementing a closed single sign-on system, you can do the following: 1. Make the OpenID provider implement an identifier select endpoint. 2. Make the OpenID provider automatically authenticate users who have already authenticated (perhaps just to known sites). 3. For the relying party sites, if the user is unknown (according to local session cookie), begin an OpenID authentication request to the identifier select endpoint. The result will include the user's identity. The system we're building would most likely include SSO, so most of this would already happen. The additional thing CAS offers is that we won't force you to authenticate if you haven't already, but we will take advantage of the fact that you have if you did already (i.e. for a portal, if you haven't authenticated we'll just show a guest layout, but if you have, we'll actually display your layout). My guess is we'll probably have to propose our own extension for this. If you are designing an open system (user can use whatever provider they want), I don't think there is an answer to this (which provider are you asking whether the user is authenticated to?). We're actually considering developing a two-tier system. Locally, we'll still be interested in using OpenId, but we'd probably point all of our local apps to a central server. Then our central server would be able to handle local users or delegate out to other OpenId servers. 2. Similar to above, we support a concept of opting-out and forcing re-authentication. So an application that contains SSNs may basically tell the authentication server, I don't care if they've authenticated already, do it again. The PAPE extension would be appropriate here: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html A relying party site can ask the OP to reauthenticate the user if they were previously authenticated more than N seconds ago (N can be zero). Of course, there is nothing to prevent an OP from lying about reauthenticating the user. If that matters to you, then only accept OpenID providers you trust. The last question: We don't actually do this in CAS yet, but we've seen it and a few people have asked for it. Is there a way to pass information along
Re: Accessing Service on Behalf of the User--supported in OpenId?
On Thu, Aug 21, 2008 at 12:49 AM, Scott Battaglia [EMAIL PROTECTED] wrote: Thanks for the reply...some comments in-line! On Fri, Aug 15, 2008 at 6:26 AM, James Henstridge [EMAIL PROTECTED] wrote: 2008/8/15 Scott Battaglia [EMAIL PROTECTED]: snip / 1. Do you guys support accessing a service on behalf of a user. In CAS we call this proxying on behalf of the user. But essentially, if you're say, a portal, and you need to access the grades, you would retrieve a CAS proxy ticket and give it to the grades service which would resolve that to the user as well as the chain of where it came from. 2. Use OAuth. The portal acquires an access token to the grades service. This involves sending the user to the grades service to authenticate (which might be done using OpenID). The portal can then use the access token to request the data directly from the grades service. This seems like a more viable solution. This is probably more of a OAuth user list question but I figure I'll check here first. It doesn't look like OAuth does attribute exchange, is that true? Or is there an extension we could use (or a standard way to add extensions). My guess is that would start to get a little weird because if there's no interaction then there is no way for a user to approve/deny attribute exchanges unless there's a central decision made about attribute releases (which may work for us, but probably doesn't work in a general case) OAuth really only defines two things: 1. how the consumer acquires an access token used to talk to the service provider on behalf of the user. 2. how communication between the consumer and service provider is authenticated. It doesn't define what the service provider's API look like, so that part would be up to you to define. Some of the other stuff is more related to local SSO needs than the actual protocol, but I'll ask anyway: 1. Do you support a method of determining whether someone has authenticated already (in CAS we call it gateway)? For us it relies on the fact that you always point to one CAS server, which obviously doesn't need to be true in the case of OpenId.However, in the scenario where you know there is only one authenticating server, is this possible? If you are implementing a closed single sign-on system, you can do the following: 1. Make the OpenID provider implement an identifier select endpoint. 2. Make the OpenID provider automatically authenticate users who have already authenticated (perhaps just to known sites). 3. For the relying party sites, if the user is unknown (according to local session cookie), begin an OpenID authentication request to the identifier select endpoint. The result will include the user's identity. The system we're building would most likely include SSO, so most of this would already happen. The additional thing CAS offers is that we won't force you to authenticate if you haven't already, but we will take advantage of the fact that you have if you did already (i.e. for a portal, if you haven't authenticated we'll just show a guest layout, but if you have, we'll actually display your layout). My guess is we'll probably have to propose our own extension for this. If you are designing an open system (user can use whatever provider they want), I don't think there is an answer to this (which provider are you asking whether the user is authenticated to?). We're actually considering developing a two-tier system. Locally, we'll still be interested in using OpenId, but we'd probably point all of our local apps to a central server. Then our central server would be able to handle local users or delegate out to other OpenId servers. If you're using that system, I guess you could define some kind of OpenID extension that requests cancel the authentication request if the user is not authenticated and combine that with an identifier select authentication request. The central server might also help address some of the trust issues that exist with specifications like PAPE. James. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Accessing Service on Behalf of the User--supported in OpenId?
2008/8/15 Scott Battaglia [EMAIL PROTECTED]: Hi everyone, I'm the lead developer on the JASIG Central Authentication Service, one of the SSO servers that a number of higher education institutions use. Traditionally, CAS has used its own de-facto standard protocol (CAS1 and CAS2) which are similar in concept to much of OpenId 1.1. We have a couple of additional things built in (and you guys have some stuff we don't as optional specifications). As part of the evolution of the CAS SSO server, we've been including support for additional protocols beyond CAS. To date, we can support CAS1, CAS2, SAML 1.1, part of SAML2 and are an OpenID 1.1 provider (the dumb model). We're looking to expand CAS into the realm of federation. We've been looking at SAML2 which while extremely powerful can also be very complex and goes against the concepts we've introduced in CAS1 and CAS2 (i.e. simplicity of protocol). OpenId gives us a much warmer, fuzzy feeling :-), so we're doing some initial analysis of utilizing OpenId 2 as our method for federation (in the nice boxes we've drawn on our white board it seems to work well). I just have a few questions for a comparison of the OpenId protocol vs. the CAS protocol that we're obvious to me. The main question is: 1. Do you guys support accessing a service on behalf of a user. In CAS we call this proxying on behalf of the user. But essentially, if you're say, a portal, and you need to access the grades, you would retrieve a CAS proxy ticket and give it to the grades service which would resolve that to the user as well as the chain of where it came from. There are a few models that can be used for this: 1. The user goes to the grades service and requests that their data get transferred to the OpenID provider via the attribute exchange protocol. When they go to the portal site, the portal can request the data from the OP, again using attribute exchange. Of course, in this model there is no direct contact between the portal and grades service in this model, so the portal would need some way of verifying that the data it got was correct. Digital signatures are probably the answer here, but there is no standard for this yet (there was a proposal for this a while back though). 2. Use OAuth. The portal acquires an access token to the grades service. This involves sending the user to the grades service to authenticate (which might be done using OpenID). The portal can then use the access token to request the data directly from the grades service. Some of the other stuff is more related to local SSO needs than the actual protocol, but I'll ask anyway: 1. Do you support a method of determining whether someone has authenticated already (in CAS we call it gateway)? For us it relies on the fact that you always point to one CAS server, which obviously doesn't need to be true in the case of OpenId.However, in the scenario where you know there is only one authenticating server, is this possible? If you are implementing a closed single sign-on system, you can do the following: 1. Make the OpenID provider implement an identifier select endpoint. 2. Make the OpenID provider automatically authenticate users who have already authenticated (perhaps just to known sites). 3. For the relying party sites, if the user is unknown (according to local session cookie), begin an OpenID authentication request to the identifier select endpoint. The result will include the user's identity. If you are designing an open system (user can use whatever provider they want), I don't think there is an answer to this (which provider are you asking whether the user is authenticated to?). 2. Similar to above, we support a concept of opting-out and forcing re-authentication. So an application that contains SSNs may basically tell the authentication server, I don't care if they've authenticated already, do it again. The PAPE extension would be appropriate here: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html A relying party site can ask the OP to reauthenticate the user if they were previously authenticated more than N seconds ago (N can be zero). Of course, there is nothing to prevent an OP from lying about reauthenticating the user. If that matters to you, then only accept OpenID providers you trust. The last question: We don't actually do this in CAS yet, but we've seen it and a few people have asked for it. Is there a way to pass information along to say something like I need them to authenticate via username/password, or cert, or LOA2 or higher? Again, the PAPE extension should handle this. Thanks for any answers you guys can provide. We'll be continuing to do research into how OpenId2 fits into the CAS world, but I wanted to see if I could get some of these basic protocol comparison questions out of the way. James. ___ specs mailing list specs@openid.net
Accessing Service on Behalf of the User--supported in OpenId?
Hi everyone, I'm the lead developer on the JASIG Central Authentication Service, one of the SSO servers that a number of higher education institutions use. Traditionally, CAS has used its own de-facto standard protocol (CAS1 and CAS2) which are similar in concept to much of OpenId 1.1. We have a couple of additional things built in (and you guys have some stuff we don't as optional specifications). As part of the evolution of the CAS SSO server, we've been including support for additional protocols beyond CAS. To date, we can support CAS1, CAS2, SAML 1.1, part of SAML2 and are an OpenID 1.1 provider (the dumb model). We're looking to expand CAS into the realm of federation. We've been looking at SAML2 which while extremely powerful can also be very complex and goes against the concepts we've introduced in CAS1 and CAS2 (i.e. simplicity of protocol). OpenId gives us a much warmer, fuzzy feeling :-), so we're doing some initial analysis of utilizing OpenId 2 as our method for federation (in the nice boxes we've drawn on our white board it seems to work well). I just have a few questions for a comparison of the OpenId protocol vs. the CAS protocol that we're obvious to me. The main question is: 1. Do you guys support accessing a service on behalf of a user. In CAS we call this proxying on behalf of the user. But essentially, if you're say, a portal, and you need to access the grades, you would retrieve a CAS proxy ticket and give it to the grades service which would resolve that to the user as well as the chain of where it came from. Some of the other stuff is more related to local SSO needs than the actual protocol, but I'll ask anyway: 1. Do you support a method of determining whether someone has authenticated already (in CAS we call it gateway)? For us it relies on the fact that you always point to one CAS server, which obviously doesn't need to be true in the case of OpenId.However, in the scenario where you know there is only one authenticating server, is this possible? 2. Similar to above, we support a concept of opting-out and forcing re-authentication. So an application that contains SSNs may basically tell the authentication server, I don't care if they've authenticated already, do it again. The last question: We don't actually do this in CAS yet, but we've seen it and a few people have asked for it. Is there a way to pass information along to say something like I need them to authenticate via username/password, or cert, or LOA2 or higher? Thanks for any answers you guys can provide. We'll be continuing to do research into how OpenId2 fits into the CAS world, but I wanted to see if I could get some of these basic protocol comparison questions out of the way. Thanks -Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
