¿Cómo usar SSO usando rally.restapi.dll?

Question

hasta ahora, he leído que Rally Restapi no es compatible con el inicio de sesión de SSO.Creo que esto ya no es cierto a partir de enero de 2014. La misma API se usa en el complemento de Rally para Excel (aquí está enlace para complemento de rally para Excel ) que admite el inicio de sesión de SSO.¿Puedo obtener el código fuente de Rally Excel Add-in o al menos alguien, proporcione un ejemplo de SSO utilizando Rally Restapi?

Quiero hacer exactamente lo mismo lo que hace la funcionalidad de Excel Addin Export, pero quiere hacer en la aplicación Pure .NET.

Answer 1

He agregado un howto a la API de REST C # que explica cómo hacer una autenticación de SSO, como lo hace Rally en el plugin de Excel. Lo pongo aquí por conveniencia.

Gracias, Scott

Un breve rally SSO PRIMER

El Rally Web Services API (WSAPI) admite solo la autenticación básica. Usando la autenticación básica, las sesiones WSAPI deben iniciarse con un nombre de usuario y una contraseña que se valida contra una lista de nombres de usuario y contraseñas almacenados directamente en Rally. Esto funciona bien hasta que los clientes comiencen a usar un signo único (SSO). SSO permite a los clientes usar un mecanismo de autenticación de toda la empresa (como LDAP o Active Directory) para administrar las credenciales y las contraseñas de los usuarios. Hasta ahora, el uso de WSAPI con SSO habilitado ha requerido que los clientes mantengan una lista de usuarios duplicados (la lista "Blanco") en Rally para todos los usuarios que deseen usar el Rally WSAPI. Los cambios recientes para Rally ahora permiten a los usuarios de WSAPI acceder a Rally utilizando sus credenciales de SSO y aliviar la necesidad de mantener a los usuarios en la lista "Blanco".

Nota: la implementación actual de SSO de Rally se basa en la especificación SAML que requiere que un usuario interactúe con un navegador para completar la autenticación. Como tal, esta técnica requiere que el usuario interactúe con un navegador, por lo que es incompatible con los clientes de WSAPI sin cabeza como los que sincronizan el rally con VCS y herramientas de seguimiento de errores.

Al iniciar una conexión SSO, el usuario proporciona una URL que inicia el apretón de manos de SSO con el proveedor de servicios (SP) de Rally, que involucra más adelante el proveedor de identidad del cliente (IDP) y finaliza con el rally que responde con cookies que representan una sesión autenticada válida . Si esa cookie de sesión autenticada se incluye en cualquier llamada WSAPI posterior, Rally asociará las llamadas con el usuario autenticado y las llamadas WSAPI se autenticarán. Para facilitar el acceso a la cookie de sesión autenticada para fines de las llamadas WSAPI después de una autenticación de SAML SSO exitosa, Rally busca un parámetro agregado a la URL inicial de SSO que si está presente devolverá una página web especial que contenga la cookie de la sesión en Borrar Texto como producto final del apretón de manos de SSO. Los usuarios pueden usar los datos para construir una cookie que se utilizará en las llamadas WSAPI posteriores.

NOTA: Las URL de ejemplo a continuación son (potencialmente) específicas para la implementación interna de SSO de Rally. Dado que se utiliza SSO para permitir a los clientes proporcionar su propia autenticación utilizando su propia infraestructura de SSO (al menos la parte IDP), las URL de SSO serán específicas del cliente. Póngase en contacto con su Rally Tam o Support Rally para obtener ayuda con las URLS de SSO.

Una URL de SSO original se ve algo así:

 https://sso.rallydev.com/sp/startSSO.ping?PartnerIdpId=pingidp.f4tech.com-29577

El parámetro especial es:

 TargetResource=https://us1.rallydev.com/slm/j_sso_security_check?noRedirect=true

Nota: este nombre / par de valor establece el relevo SSO en la implementación de SSO específica de Rally utilizando Pingidentity como proveedor de SSO. Otros proveedores de SSO pueden tener un nombre de parámetro diferente utilizado para establecer el relevo. Por ejemplo, algunos proveedores de SSO usan reléstate como el nombre del parámetro. En cualquier caso, el valor es siempre el mismo (es decir, " https://us1.rallydev. com / slm / j_sso_security_check? Noredirect= True ")

Así que se vería una URL completa:

 https://sso.rallydev.com/sp/startSSO.ping?PartnerIdpId=pingidp.f4tech.com-29577&TargetResource=https://us1.rallydev.com/slm/j_sso_security_check?noRedirect=true

Si un usuario navega a esta URL de SSO modificada, después de la autenticación, se presentarán con una página web que contenga lo siguiente:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
    <head>
        <title>SSO Token</title>
    </head>
    <body>
        <form>
            <input type="hidden" name="authCookieName" value="ZSESSIONID"/>
            <input type="hidden" name="authCookieValue" value="khkjhkhkhkhkjhh"/>
        </form>
    </body>
</html>

Si el usuario crea una cookie según los datos contenidos en esta página y pasa esa cookie junto con sus llamadas WSAPI posteriores, esas llamadas se autenticarán con éxito. Tenga en cuenta que los datos de cookie opcionales similares, como Secure y Ruta, deben inferirse de la llamada realizada para obtener la cookie según la especificación IETF para las cookies.

El proceso básico para iniciar sesión en un mitin de una interfaz GUI (nuevamente, esto no funciona para entornos sin cabeza) con el fin de emitir llamadas WSAPI es la siguiente:

• Recoge la URL de SSO del usuario con el parámetro especial descrito anteriormente.
• lanzar un navegador apuntado a esa URL.
• Después de completar la navegación, raspe los valores de la cookie de la página HTML devuelta.
• cerrar el navegador.
• construir una cookie de los valores de las cookies.
• almacena esa cookie para su uso posterior.
• envíe esa cookie con todas las llamadas WSAPI posteriores.

Repetir este proceso si la llamada WSAPI falla por la autenticación usando esta cookie. Recuerde que estas cookies expiran y debe estar preparada para volver a intentar una llamada fallida después de la re-autenticación para crear una experiencia de usuario sin problemas.

Rally C # REST API

El Rally C # REST API tiene un mecanismo integrado en su marco de conexión para hacer que este proceso sea fácil para diferentes clientes de GUI, incluida la re-autenticación automática después del tiempo de espera de la sesión. Esto incluye métodos para analizar la página de token en una cookie válida. Las personas que llaman de esta biblioteca pueden implementar otra FEA

TURES, como inferir datos de cookies opcionales (como dominio, ruta, seguridad y puerto host) para tener en cuenta las situaciones (como entornos de prueba) donde Rally no devuelve los datos completos de cookies.

Conexión a la rally usando la API de REST C # significa construir una instancia de RallyRestapi. Hay dos constructores heredados que asumen la autenticación básica y toman el nombre de usuario y la contraseña, entre otros parámetros. Construir un rallyrestapi usando uno de estos constructores siempre usará la autenticación básica y nunca usará SSO.

Un tercer constructor requiere solo un objeto IconnectionInfo. Esta es la forma preferida de obtener un rallyrestapi. El uso de un objeto IconNeccionalInfo para construir un RallyRestapi permite a la persona que llama especificar toda la información de conexión en un objeto que se puede usar para las devoluciones de llamadas de la SSO y el intercambio de autenticación entre múltiples instancias de RallyRestapi.

IconnectionInfo y ConnectionInfo

Para facilitar la autenticación SSO, la API de REST C # presentó la interfaz IconNeccionalInfo y la clase ConnectionInfo. Estas clases representan un objeto que mantiene las preferencias de conexión y puede iniciar y completar una sesión de autenticación SSO basada en el navegador cuando se solicita que lo haga. La clase ConnectionInfo implementa todas las preferencias de conexión y tiene métodos para analizar la página de destino de Rally SSO en una cookie utilizable. Esta clase se puede utilizar como si solo se requiere autenticación básica. Iconnectioninfo está ahí para la flexibilidad en caso de que la persona que llama no quiera extender o usar de otra manera ConnectionInfo.

Cuando use iconnectioninfo para autentica básica, simplemente cree una nueva conexión de conexión y establezca los campos apropiados para accesibles públicamente. Usa que para construir un rallyrestapi. Cualquier error de autenticación tirará excepciones.

Example:

var cInfo = new ConnectionInfo();
cInfo.UserName = "myName";
cInfo.Password = "pass";
cInfo.Server = new Uri("https://host.com");
cInfo.AuthType = Rally.RestApi.AuthorizationType.Basic;

var conn = new RallyRestApi(cInfo);

Cuando use iconnectioninfo para SSO, la persona que llama debe implementar DOSSOAUTH (). A continuación se muestra un ejemplo anotado.

public class MyConnectionInfo : Rally.RestApi.ConnectionInfo
{
    public override void doSSOAuth()
    {
        // Launch a browser to the this.server URI.
        // The browser will close automatically if it successfully reaches the SSO landing page 
        // Users can cancel the SSO handshake
        // Abort if the handshake is successful, but didn't arrive at the SSO landing page
        var ssoDialog = new SSOAuthDialog(server);
        DialogResult result = ssoDialog.ShowDialog();
        if (result == DialogResult.Cancel)
            throw new Exception("SSO authorization canceled");
        else if (result == DialogResult.Abort)
            throw new Exception(ssoDialog.abortReason);

        // Parse the SSO landing page into a Cookie and save it
        AuthCookie = parseSSOLandingPage(ssoDialog.getBrowser().DocumentText);

        // Infer Cookie values from SO Landing Page URL if not set
        if (String.IsNullOrWhiteSpace(authCookie.Domain) || authCookie.Domain == "null")
            authCookie.Domain = ssoDialog.getBrowser().Url.Host;
        AuthCookie.Secure = String.Equals(ssoDialog.getBrowser().Url.Scheme,"https",StringComparison.InvariantCultureIgnoreCase);

        // Set a specific port port if the SSO Landing Page URL has one
        if (!ssoDialog.getBrowser().Url.IsDefaultPort)
            Port = ssoDialog.getBrowser().Url.Port;
    }
} 

Este ejemplo utiliza un cuadro de diálogo WinForms con un componente del navegador para presentar el apretón de manos del SSO al usuario. Recuerde, puede usar cualquier tecnología de pantalla que desee implementar esta parte. Aquí hay un ejemplo anotado:

public partial class SSOAuthDialog : Form
{
    public String abortReason;

    public SSOAuthDialog(Uri url)
    {
        InitializeComponent();
        webBrowser.Url = url;
    }

    private void documentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
    {
        // We have found the SSO Landing Page.
        if (webBrowser.DocumentText.Contains("authCookieName") && webBrowser.DocumentText.Contains("authCookieValue"))
        {
            Trace.TraceInformation("Found SSO authentication token on page: {0}", e.Url.AbsolutePath);
            DialogResult = DialogResult.OK;
            Close();
        }

        // We have landed on the Rally ALM page
        // This is usually caused by a bad URL 
        else if (webBrowser.DocumentText.Contains("window.FEATURE_TOGGLES"))
        {
            abortReason = String.Format("The SSO handshake was successful, but the 'RelayState' was not correctly set. Contact your administrator to obtain the correct URL parameter to set the SSO handshake 'RelayState' to: https://rally1.rallydev.com/slm/j_sso_security_check?noRedirect=true");
            Trace.TraceError(abortReason);
            DialogResult = DialogResult.Abort;
            Close();
        }
    }

    public WebBrowser getBrowser()
    {
        return webBrowser;
    }
}

SSO Example:

var cInfo = new MyConnectionInfo();
cInfo.Server = new Uri("https://host");
cInfo.AuthType = Rally.RestApi.AuthorizationType.SSO;

// This will cause an SSO authentication event
var conn = new RallyRestApi(cInfo);
// This will not b/c it will just use the auth Cookie already in cInfo
var conn2 = new RallyRestApi(cInfo);

Cuando use iconnectioninfo para SSO, es importante almacenar en caché el objeto IconNeccionalInfo que envíe para construir un rallyrestapi. Después de un exitoso apretón de manos de SSO, la cookie de autenticación resultante se almacena en el objeto IconnectionInfo y se utilizará para todas las llamadas WSAPI posteriores hechas de ese objeto RallyRestapi. Si necesita crear otro objeto RallyRestapi utilizando la misma cookie de autenticación de un inicio de sesión de SSO anteriormente exitoso, simplemente construya un nuevo objeto RallyRestapi con el mismo objeto IconNeccionalInfo y si hay una cookie de autenticación presente, se utilizará.

Reintentos

Las cookies de autorización pueden caducar. La API de C # REST detectará una cookie SSO caducada e iniciará una nueva sesión de inicio de sesión de SSO según sea necesario para obtener una nueva cookie válida.

Eso es todo lo que hay.

Answer 2

SSO no está respaldado actualmente por nuestros kits de herramientas.Utilizamos algunos hacks especiales para que funcione para el complemento de Excel, pero nada con una interfaz que es lo suficientemente fácil de usar para compartir con nuestra comunidad de desarrolladores.

Estamos trabajando en una solución de OAUTH que debería hacer que los proyectos les guste mucho más.Una vez que se envía, debemos publicar un blog para mostrarle qué características tiene.Mi esperanza personal es que todos nuestros kits de herramientas tendrán apoyo para hacer uso de OAuth Simple.