Hi Steve, Yes, there is a services registry, but no, it's not relevant. [1]
Rather, ClearPass accepts proxy tickets and discriminates among the purveyors of proxy tickets just like any other CAS client application. This is the elegance of ClearPass -- the /cas/clearPass endpoint is just another CASified service that accepts proxy tickets. As such: the way to restrict which services are able to retrieve credentials from ClearPass is to restrict which proxy chains are authorized in the configuration of the Jasig Java CAS client in front of ClearPass. That is, in web.xml, there's an init-param on the CASValidateFilter that enumerates authorized proxy chains. Your portal's pgtUrl should be authorized, so that uPortal can get that password. Possibly, the pgtUrl of a component fronting Outlook Web Access or the Exchange calendar web service endpoint should be authorized, so that that component can call ClearPass to get the end user's credential. Carefully selected other such ClearPass-reliant services should be enumerated in that init-param value. And, of course, no other services should be so enumerated. That's how you constrain which services have access to get those credentials from ClearPass. Responsibility for scrutinizing the presenting proxy chain and determining whether and what to do about it lies firmly with the application accepting CAS proxy tickets. There's an "acceptAnyProxy" init-param that you can set to true. It's rare that it's appropriate to set that parameter to true. It's a very bad idea to "acceptAnyProxy" unless it's really true that something further along in the application is going to programmatically scrutinize that proxy chain, say, in a way not supported by the basic in-the-enumerated-set-or-not logic supported by the Jasig Java CAS Client. Though getting dated, I think this presentation is still pretty relevant for the over all ClearPass picture: http://vimeo.com/11630521 Kind regards, Andrew [1]: The CAS services registry currently allows you to register which services are "allowed to proxy". I guess that's fine as far as it goes, but it doesn't go nearly far enough -- that a service is allowed to proxy to *something* doesn't mean that it should necessarily be allowed to proxy to *anything in particular*. Rather, in the current architecture, responsibility for scrutinizing the presented proxy chain and determining whether and how to service the request lies squarely with the application accepting CAS tickets, in the same way that deciding whether and how to service a particular presenting user lies squarely with the application accepting CAS tickets. CAS is a speaker of truth. The truth might be that the presenting user, or presenting proxy chain, isn't one that your application would like to service. On Dec 15, 2011, at 5:13 PM, Steve Swinsburg wrote: > Hi Andrew, > > Thanks for all of the info. I am thinking we may need to use ClearPass so the > portal can get the credentials and release them to portlets as required. We > also want to use cached credentials for the Email Preview portlet rather than > having the user enter their password again, so this might solve the problem > for both portlets. > > For ClearPass, I've found this doc: > https://wiki.jasig.org/display/CASUM/ClearPass but it is unclear how I can > restrict what service can participate in ClearPass. Is there some sort of > services registry? Are there any other docs on the security side? We need to > be absolutely certain that plain text credentials are not going to be > intercepted or used by anything except the very small set we specify. I've > cross posted to the CAS list. > > cheers, > Steve > > > On 16/12/2011, at 1:02 AM, Andrew Petro wrote: > >> Steve, >> >> One integration pattern to be had here: >> >> Portal presents proxy CAS ticket to (small shim in front of) Exchange. >> (small shim in front of) Exchange validates the proxy ticket, obtains a PGT, >> obtains a PT to the CAS ClearPass service, uses the PT to obtain the end >> user's password from the CAS ClearPass service, and internally posts the >> with-password request to the Exchange service, proxying back the response to >> the portal. >> >> Password replay, but in this approach, the password isn't in the portal, nor >> is it replayed through the browser -- the password's just at CAS and at >> Exchange, places where it is already. >> >> Not perfect, but that's the flavor of CASifying Outlook Web Application, >> anyway. >> >> Kind regards, >> >> Andrew >> >> >> >> On Dec 15, 2011, at 8:53 AM, Andrew Petro wrote: >> >>> Steve, >>> >>> Off-the-cuff response: >>> >>> I don't believe a CAS proxy ticket would be sufficient to authenticate the >>> calendar portlet to Exchange to obtain the users' calendar information, no. >>> I believe Exchange needs that end user password to authenticate the >>> request for the users' information. >>> >>> I don't know offhand if it's possible to use something other than the end >>> user's password to authenticate the request. If so, then there'd be some >>> approach in CASifying the Exchange web services or introducing a CASified >>> intermediary that translates between a CAS proxy ticket and an >>> authentication abstraction that Exchange requires. >>> >>> I suppose that CASified intermediary could be equipped with the credentials >>> of a plenipotent Exchange account capable of reading everyone's calendar. >>> It could access Exchange as that more privileged user, taking care to read >>> only the calendars of the user authenticated to it by the proxy CAS ticket. >>> >>> Anyway. I haven't personally actually done an Exchange calendar >>> integration other than by replay of the end user's password credentials. >>> Others may know more or have a solution. >>> >>> Hope this helps, >>> >>> Andrew >>> >>> On Dec 14, 2011, at 9:28 PM, Steve Swinsburg wrote: >>> >>>> Hi, >>>> >>>> We are interested in the Exchange support in the Calendar portlet. I have >>>> configured it all according to: >>>> https://wiki.jasig.org/display/PLT/Calendar+Portlet+Exchange+Integration >>>> >>>> However our portal is CASified so we don't have the password user >>>> attribute available. Is it possible to use the CAS Proxy feature of the >>>> calendar portlet in conjunction with the Exchange adapter? >>>> >>>> cheers, >>>> Steve >>>> >>>> >>>> -- >>>> You are currently subscribed to [email protected] as: >>>> [email protected] >>>> To unsubscribe, change settings or access archives, see >>>> http://www.ja-sig.org/wiki/display/JSG/portlet-user >>>> >>> >> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/portlet-user >> > > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
