Estoy tratando de crear algo como: el cliente se autentica y obtiene el token del STS1 personalizado, el siguiente cliente autoriza con la clave de la máquina y recibe el token en el STS2 personalizado y obtiene otro token. Con el último token, el cliente solicita métodos en el servicio RP.
Todos los servicios están alojados en IIS y utilizan un escenario de federación activa. Ambos STS tienen extremos con enlaces ws2007Federation y ws2007Http, y RP usa ws2007FederationBinding con STS2 como emisor.
Si creo un canal con CreateChannelWithIssuedToken, solo puedo ver el token de STS1 y no puedo obtener el token de STS2.
Así que decidí pasar el token de STS1 como propiedad de ActAs RST a pedido del token STS2. Y eso falló: no se puede descifrar el token.
Por lo general, solo querrá utilizar un token en cada paso. Entonces, si necesita fusionar reclamos, querrá hacerlo en el paso de transformación de reclamos del segundo STS.
Entonces, el flujo se autenticaría con STS1, luego se autenticaría con STS2 con el token de STS1. En ese momento, pasaría por los reclamos y los transformaría para agregar reclamos adicionales según sea necesario. Entonces el Token resultante estaría listo para consumir desde la aplicación RP.
De hecho, comencé una serie de blogs sobre un escenario muy similar que diseñamos recientemente. No quiero ser demasiado autopromocionado, pero no me hace ganar dinero, así que lo publicaré en caso de que sea útil.
http://www.livingthearchitecture.com/mixing-sso-with-existing-technologies/
Me encantaría profundizar más, pero dependiendo de los detalles de su escenario, los detalles de la solución cambiarán mucho. Creo que lo anterior expresa el enfoque general que deseará. Déjame saber si puedo ayudar más.