Why can't I go directly to the Oracle sign on page?
When I paste this URL (below) into my web browser... Chrome or IE
https://login.oracle.com/mysso/signon.jsp
I get an error saying ...
Error! Do not use bookmarked URL.
Please type the URL you are trying to reach directly into your browser.
However, if I paste this URL into my browser (below)
http://www.oracle.com/us/corporate/contact/about-your-account-070507.html
then click the Sign In/Register link my browser takes me to the same URL (at top) but without an error.
My question is.. How can I go directly to this URL (https://login.oracle.com/mysso/signon.jsp) without having to go to some 'other' URL on the site first?
Solution 1:
My first guess was that the page you are trying to access requires that a token be in place before it'll load correctly. It appeared that you could quickly register this token with the server and go to the page by following this link:
https://login.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login?Site2pstoreToken=v1.2~656BF073~512EDAC9FEA5F9140AE8A612213BCA280B4FF70D159812B6FDF2EB8D5CA98482EB385D4542873325FB366CCD4F17E21E1329A9531F844D92AC97A70A8287652D76277798A2DDF3D738EAB735E756B24FFDF89DC77C46F81AE712DB7D4F3A0CAF8EB1AE708C04FC58FEAC6D44A4DCCA81BD967FA1AD32ED298B5563DABC10443620E45DC539A7F6E5A5AB22A2F7541EF9B3339AFE4EBBC920989B7E7556B3B6DBF84FA7643382B2907A6183D06FDD9E1358A534083E4B73A5FB6BA840A981AE3A41BF878240DA4C48C74765E10DF30AC91057225CDC77C9241409FE189D251B2EAFF14E9776ADDC3C81541F53CFFC745A1A93DFAAD06B496B5630E1A725266B84DA43FEB216463D4C89A6164441B7CEFC600CC991B549A52BC45550156A365C699CF8A89250427BA9
While that token may have been useful for other stuff. I've since found that it is not actually needed. By looking at the headers that this link caused to be posted I was able to determine that I would be able to duplicate the results of (most of) what happened when you followed that link by simply creating this HTML form to do the post for me:
<html>
<head>
<title>Oracle SSO</title>
</head>
<form method=post action="https://login.oracle.com/mysso/signon.jsp">
<input name=site2pstoretoken value="v1.2~656BF073~512EDAC9FEA5F9140AE8A612213BCA280B4FF70D159812B6FDF2EB8D5CA98482EB385D4542873325FB366CCD4F17E21E1329A9531F844D92AC97A70A8287652D76277798A2DDF3D738EAB735E756B24FFDF89DC77C46F81AE712DB7D4F3A0CAF8EB1AE708C04FC58FEAC6D44A4DCCA81BD967FA1AD32ED298B5563DABC10443620E45DC539A7F6E5A5AB22A2F7541EF9B3339AFE4EBBC920989B7E7556B3B6DBF84FA7643382B2907A6183D06FDD9E1358A534083E4B73A5FB6BA840A981AE3A41BF878240DA4C48C74765E10DF30AC91057225CDC77C9241409FE189D251B2EAFF14E9776ADDC3C81541F53CFFC745A1A93DFAAD06B496B5630E1A725266B84DA43FEB216463D4C89A6164441B7CEFC600CC991B549A52BC45550156A365C699CF8A89250427BA9" />
<input name=v value="v1.4" />
<input name=p_submit_url value="https://login.oracle.com:443/sso/auth" />
<input name=p_cancel_url value="http://www.oracle.com" />
<input name=p_error_code value="" />
<input name=ssousername value="" />
<input name=subscribername value="" />
<input name=authn_try_count value=0 />
<input name=contextType value=external />
<input name=username value=string />
<input name=contextValue value="/oam" />
<input name=password value=sercure_string />
<input name=challenge_url value="https://login.oracle.com/mysso/signon.jsp" />
<input name=request_id value=-4782010454026398257 />
<input name=OAM_REQ value="VERSION_4~VeXlMi8vRU%2fhyhTAezfX%2fU92tvWZdduOvqF%2b%2fZcYUDnWrzu4V%2fcd4uyZvxIJbR7IxaYlaMA0wEkYKHSaDT5s7MPlYk3PRIlWNYxRTtYnK0kS2JQZrKDOL4CStRvsWAbuaMQJepMzUvRrxCEamyAH0sRT5caX3lCeI1iS7znsSTNIOXOl%2fgzOIoCD4JTPfO6WAbGiW3HdRBx5Y%2bDUrjsA%2fTPURYUU%2bXZ2XpPD%2fzWu11oXQV9C9lR36H8x97UkYcjyjtT%2b9vdHp8a0QwbAxG26N4eDokGnz5MRKaILo%2bsm2itImqCAlaTDWPBhTisfT89Av8Vv6FYAG%2bUDwj1BtTpshXinS0YHDwGAGYK7GB1VIeXraYIhR7V7C92H7dMGl8j%2fNof7JiN%2fjPEIRLjnX%2fgWNqNRzRaJe%2be7LVUrbOfGkvr2l%2fuAtYhY%2b9Q%2b2QvyHp%2bESS4Mnt4We6TdZ7Ap4zQbV3ZWh2f8vbBJYSw25R77Q2JatsjQQCJnAbKtwKwmauNHZgdo8yeeq7KZoltgciAZq9cm34CgQ3IburhracegH%2bFc9jV%2fnfu8BknpoIAjgDOdxtguYtoQpKitkwCGsQLPm9oaxE0n8wbJLWta2Vj7RLh5HmF7Za%2btda6t%2fW9MweMWiq66MvGZtDIa8pNycALi4SHtfp1SiVlhABeuVftbaoM%2fDStyjbPEUXEJBxLVYOiMODjov0GtsD5ZTzP9NH39ata8fZvHjyXUxTgZmhJQsZPH4r5ks2cz2tV%2bpw5Gb4U2Wvl81iXlVcSfiwGSp55qs9xSbJkQkBl9eagNO20RsKBI9W9KNTo3Boku5SMVOTt%2bsPPXwiiJlkblq2Jn7GLhDX8oFH36XsSlo%2bIPqWfCgaesTXyYnnsfK%2b2u8uByuRvDy6XCuj6O0ytLp8sKhFNAGZq1JVhIrh5%2bgxiLkZ%2bL2SVVV1HsP2TweR9WkFvytSgdx06NPrNvDJKFGvlV%2f8428uz5cCAUF5cr%2bX%2fiQ42EwsF3iZF1nQcHqcF44v7CBYYGuAW%2fDr9ojnrjj%2bT6dstOScY1vjLXIpgQs83wsbc1KfA26907E42yEgV5sPexC452gIPvcq4rLRr8Hm4hhWXnMxF1kX2zZnruo7yldr2VIT%2bUy11ZT4mcW7AgSipQaTkmbOgtv3nuvipoiGq9AeEzz%2fyUQurw2BSXcsP4HgMPO2cA5G93%2bBsT90gNEiQySyDwbJShjEVrCfry6a00zDzKXaddOAzinHOe7zHXJSbSoeqOw1XzS3bv8G7gcS3XNGa3yOUP%2fhHcNdpxqa%2bwbsEag9xKvCJRxr5Zr8GZK2GWu5XU8Kx9j6XiIQtsU1%2bl8p1AaP%2bCuKFgXz6gK2YePb6DPYmhyasplXtq569ytFdaD5NOgUN2CeRqjdxoKTOlyZWfr6bNZf1hI0sYUT8FlP0O%2fQ%2bi65j2zRBKPiosOsGNwnzbDOLcF1bZfJCmOL5u6cx8QJXe2VFQewIcC%2fvt8CMFDKwz82N%2bxtYkhMs%2fj2GmACcHeuTPBNnRjAO059S6mE3FMf0hFfLarLbGW6uLCiV%2bWKPq7f6FqIAYy73e%2fW5yd6RtajzaLaA14fd2AIx62WqTCLTbQTMwDBG2Y966dZvyQwzEmfNVWp317NB%2byvdM0HE0bPKlPHs5IVPGBSBPgSPc4ICqTMprlj%2fapVfQT5cDa2m%2fqyo6Z2Rhj19uyJwzSoX4Ib%2bMP3q90E6SqligrDKxFtCDIa2Kc3As9F8sDhU7%2bgvYXX%2bABP1GAGFtlDhq%2fA4vq%2bkD4%2bIFtq2hg1svtuPA7YwajG5z1ZZF1EsZqbKCZKCe8nJKe2GZDf3miXR1%2fAZgTnjmaks7vTHwkB9k48YNomqgSBsqPSOYRNVOIYrKPsKeRMf6xvKCpEl6Whst5E1BsT1zWl6WZPhcn%2f0ABsl%2b5AUtZ%2bvKqI%2fyymq1zOidcpn6Ao%2bO55wSAj%2botPbUr1UyrQbMFlV7jWJPYOs%2bicDSRf1DZlC1w5rsIUz7HRAjVcc4yyRnTwOeGXnoUTuzoHJ5PhmxpBIbr0otlfiDMHY6cm960PvYDAtWUSgOnwA4%2bPtY4YtmBSZuvSrk3W7L%2f1%2fTaYGb0uccJx1sfB6qwD1Isk80NxnKWCCftv0W0AE3zf9xpei1SWNp%2fMJH1yfpVFM%3d" />
<input name=locale value=en_US />
<input type="submit" value="Submit">
</form>
</html>
As you can see, the referrer is not critical here. All that matters is that the login form is given the information contained in the setup form. I still don't know where to get those tokens aside from the main site though, you'll need to figure that out yourself.
After playing around with this a little more, I found out that the only value on the form above which matters is the request_id. The following, much simpler, version could be used:
<html>
<head>
<title>Oracle SSO</title>
</head>
<form method=post action="https://login.oracle.com/mysso/signon.jsp">
<input name=request_id value=-4782010454026398257 />
<input type="submit" value="Submit">
</form>
</html>
What's more, the form will accept this value as either a GET or a POST. Meaning, that you can access the form at: https://login.oracle.com/mysso/signon.jsp?request_id=-4782010454026398257
This makes things much easier. Now, you just need to find out whether or not you'll need to keep a fresh request_id around or if that one will last forever. It may not even matter what request_id you use. I don't have an account on that page (so I can't test this) but if I enter ANY number for the request_id it displays the form. Try logging in with a number you just make up like this:
https://login.oracle.com/mysso/signon.jsp?request_id=007
or with even no id at all, like this:
https://login.oracle.com/mysso/signon.jsp?request_id=
I haven't actually tested this beyond the fact that this will make the form display. Read the comments to see if anyone else has.
Solution 2:
They're doing some weird black magic based on the Referer header, which contains the URL of the previous page, if any.
Basically if the referer is present and set to another one of their pages, all is fine, otherwise they throw an error. Only they can explain why they're doing this.
This may be an attempt at increasing security, but to me this looks like a security theater as bookmarking the genuine URL seems more safe than typing and possibly mistyping the domain, which would then allow an attacker to register the mistyped domain (oralcle.com for example) and put up a phishing page.
Solution 3:
It is a "single sign on" system. The domain login.oracle.com only allows you to authenticate, but has no content on it's own. Thus, if you don't come from another domain which required you to log in, it would show you no content at all.
As there is no content at that domain and your favourites does not include any info of what you were trying to access, they just warn you that your favourite is pointing to the wrong address.
After login in and for the session duration, you may access any subdomain at oracle as an authenticated user without the need to log in again in.
It's like you usually work with google: you must login at accounts.google.com, but you usually access it using other domains (www.google.com, mail.google.com, etc)
Solution 4:
It's likely to be a centralized identity provider, which might be used by multiple systems. It looks like it's using Oracle Application Server SSO. I'm not familiar with that specific product, but such a system might look like this:
User accesses target site.
The target site redirects to the user to the login server. The redirect includes a token which provides details about the original request. (The referer header could also be used, but it would make it harder to handle cases where the initial request was a POST instead of a GET request.)
The login server accepts the token, recognizes that the user isn't yet signed in, and prompts them to log in.
The user logs in to the login server.
The login server returns the user to the originally requested resource, providing information about the original request and the user's identity back to the application.
The application recognizes and trusts the identity assertion provided by the identity provider, so it handles the original request.
One advantage to this system is that the identity system is less coupled to the application consuming the SSO services. The identity provider is responsible for authenticating users, so individual applications don't have to be concerned with the mechanics of authenticating users.
An organization could also make large changes to the authentication process without each application having to be reconfigured for the new method. This could mean enhancing password-based logins with an RSA key fob, switching to Windows Integrated Authentication, moving users from a legacy LDAP system into Active Directory, and so on.
If multiple applications use the same identity provider, then you also get the benefit of single sign-on. This means that once you've logged in to one application, the process for accessing another integrated application becomes:
User accesses target site.
The target site redirects to the user to the login server. The redirect includes a token which provides details about the original request. (The referer header could also be used, but it would make it harder to handle cases where the initial request was a POST instead of a GET request.)
The login server recognizes the user from the existing session. It returns the user to the originally requested resource, providing information about the original request and the user's identity back to the application.
The application recognizes and trusts the identity assertion provided by the identity provider, so it handles the original request.
Note that since the user is already logged in to the identity provider, all that they'll experience is a few quick redirects.