On Sat, Dec 17, 2011 at 9:59 PM, Jim Schaad <[email protected]> wrote: > I have an RP code that is written on top of GSS-API. At this point I need > to be able to do a couple of different things. > > 1. Is the RP that is my service provider going to talk directly to > the AAA proxy that is hosted with the IdP, or is it going to go through some > local AAA proxy at my side of the conversation.
A local proxy. > 2. Since as an RP I am doing all of my talking to the AAA side of the > world via GSS-API, I assume that we need to have some set of items for > controlling how the routing is going to be done in the GSS-API interface. Well, the RP application is just calling GSS_Accept_sec_context(). The mechanism invoked by GSS_Accept_sec_context() (GSS-EAP) will do all the work of talking AAA under the covers, invisibly to the application. More likely than not the application only really needs to indicate to the GSS-API that for any particular instance of the application it wants to use one or another configuration/profile. In practice there will often be a single configuration/profile anyways, so that nothing is needed here. If the application really does need direct, fine-grained control how trust routing is done we'd likely end up using a GSS extension such as naming extensions (applied to the acceptor NAME object), credential options (applied to the acceptor's CREDENTIAL HANDLE), or security context options. > We currently have a way of getting answers from IdP such as the SAML > returned (either in its entirety or in parts.) And I assume we are going to > have some way of setting the SAML request. However, is the GSS-API or the > RP code itself going to deal with the routing issues? For the sake of simplicity the GSS mechanism should deal with trust routing. The application should limit itself to inspecting the initiator (client) name returned by the GSS-API, or perhaps the application should ask for specific kinds of attributes that it wants to see, or perhaps it should simply select a profile that tells the mechanism the application's requirements. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
