launch AppScript from URL with user login


How can I launch an AppScript from URL for a given user/password? We use SSO and I tried to pass the login data via URL-Parameter like this without success:

http://server:8085/ALFSSOLogin/login.

  • I need to access the output of the AppScript from a cms (typo3).

    It seems that the source of the login page lies in

    SBM\Common\jboss405\server\default\deploy\ALFSSOLogin.war\jsp\login.jsp

  • Mike,

    I might be doing something different but my sbm is setup to use SSO as well but I still use the same url as the documentation says and the script still runs.

    http://servername/tmtrack/tmtrack.dll?ScriptPage

  • Hi Mike and Brian. Once a user is logged in, the script works in a browser via

    http://server/tmtrack/tmtrack.dll?ScriptPage

  • Michael,

    You can try to add these two parameters to your URL


  • Thanks Duru, but it's not working for me. Even if I use all three pairs of auth parameter:

    http://server:8085/ALFSSOLogin/login.

  • Hey guys,

    When using SSO there's no way to do this. SBM has several authentication types available with increasing levels of security. We do support an authentication type that allows for login parameters on the URL (Form/URL/Cookie) but this does not work for all authentication types.

    SSO is our most secure form of authentication and session management. It has a plethora of safe guards built into it, one of which is the prevention of replay attacks. This is why the above request to the login page doesn't work. We won't issue security tokens to unsolicited requests.

    To do what you're wanting to do here it would be best to have a little programmatic interaction where you go through the login process then make the request for the script to run.

  • Hi Brock,

    after all I was afraid to hear this answer.

    Could you please specify your proposed solution with the "little programmatic interaction"? Shall I modify the login.jsp ?

  • Hi Michael,

    Use the following WS-Trust request. You can call a SOAP service at

    http://hostname:8085/idp/services/Trust

    Unfortunately there is no WSDL for WS-Trust requests so you'd have to handcraft it from the snippet below.



    <?xml version="1.0" encoding="UTF-8"?>

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

    <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">

    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">

    <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

    <wsse:Username>bill</wsse:Username>

    <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"></wsse:Password>

    </wsse:UsernameToken>

    </wsse:Security>

    <wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>

    </soapenv:Header>

    <soapenv:Body>

    <wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">

    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

    <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">

    <wsa:Address>uri:org:eclipse:alf:sso:relyingparty:anonymous:anonymous:anonymous</wsa:Address>

    </wsa:EndpointReference>

    </wsp:AppliesTo>

    <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>

    <wst:TokenType>urn:oasis:names:tc:SAML:1.0:assertion#Assertion</wst:TokenType>

    </wst:RequestSecurityToken>

    </soapenv:Body>

    </soapenv:Envelope>



    Put the username and password in the wsse:Username and wsse:Password elements in the SOAP WS-Security header. The response would be either a SOAP fault if you failed or a WS-Trust RequestSecurityTokenResponse SOAP message. The response is too big for me to post here but you need to extract the token from

    soap:Envelope/soap:Body/wst:RequestSecurityTokenResponse/wst:RequestedSecurityToken/

    it will be an XML in the form of ...

    If you convert that XML to a string and then BASE64-encode it, you'd be able to include it to your calls to Application Engine in a ALFSSOAuthnToken HTTP header.

  • On a VM with 2009 R4.01, the Authentication option for "Accept Info From Form/URL/Cookie" allows me to pass either plain-text or encoded authentication info in the URL ("

  • Thanks for the answer. It seems quite a bit of work to realise this solution and I need to find the time to try.