I'm seeing something weird that I've not run across before. I've got a web app and I redirect in that web app to Azure AD to get a code that I can exchange for an access token. I've done this many times before so I'm just reusing the same code. I've created my app registration in Azure, just as I've done many times before. The problem is this - normally I can just put a host name for a Reply Url in the app configuration and then Azure AD is fine redirecting anywhere to that host.
For example, if I want to redirect to https://foo/users/processcode, I can normally just put a ReplyUrl of https://foo and it all works fine. In this one case, it says "'https://foo/users/processcode' does not match the reply addresses configured for the application blah". If I put in the fully qualified path for the ReplyUrl then it works, but for a variety of reasons that are beyond the scope here I don't want to do that.
So I'm not following why it might have a problem in this case. Wondering if anyone has seen or knows why this might be an issue all of the sudden.
Thanks.
The Redirect URL/ Reply URL has to match the exact page you want to be redirected to. You can add multiple redirect URLs to your application registration information if you want to redirect to different pages in your web site - or your web page could make the redirection for you.
Another option is to add a * in a redirect url as well (https://mywebsite.com/*) - but this only works with non-converged applications.
Related
I'm playing with the oauth2client.appengine Oauth2Decorator and it interjects it's own screen asking for an email address:
The URL is http://127.0.0.1:8080/_ah/login?continue=http%3A//127.0.0.1%3A8080/mypage
I'm guessing that its intention is to mock being different users during development? But that leaves some questions:
Does it only appear on the dev server?
Do I have to do anything to make it go away when deploying to production, or is that magic?
How do I turn it off for development?
What does it actually do?
if the user is being redirected to an oauth consent page nonetheless what's the point of this?
As you can see I just don't get it. I do see that it gives my get_current_user() a result - a user instance with the email address that I submit.
I recognise that this is effectively the same question as
"How to Bypass Local Login Screen with Oauth2 and GAE", which seems to conclude that the whole oauth2client library is fairly useless and it is best that we all go off and write own authentication flows? Seriously?
If that's the state of things alternative suggestions are welcome (in the comments). My workflow is to send the user off to be granted permissions via Google's Oauth so my webapp can proceed to do stuff on their behalf.
If you want to use the get_current_user() that is provided by Google you can't really avoid it and it is actually something very useful. If you want to do your own authentication stuff then just don't use it and you won't be redirected to /_ah/login.
In short this is just to simulate locally the actual Google Login. It would be a huge mess to login to your actual account while on development mode and it will be really hard to simulate multiple users. That code is not executed online and instead you are being redirected to Google for approval.
I have created Web Tab in salesforce with url of my application. When someone opens that tab and my application gets call, How can I make sure where user who opened it is authorized?
I know I can pass {!User.Email} and other variables to my app to identify user. I guess some sites also send {!Api.SessionId} but I can not find any information about how to authorize using Api.SessionId or any other variables that can be passed.
Update
I found https://developer.salesforce.com/page/Single_Sign_On_for_Composite_Apps which is guide to the question I asked. But not able to find jar for given java classes.
You can use the API SessionID and ServerURL to make a request back to Salesforce via the API. Say with the PartnerAPI. This will confirm that the user did indeed come from a valid Salesforce session. You can confirm other details, such as their email address from the active session as well.
Alternatively, you could create a newer connected app using signed requests. Here the request posted to you app will be signed with using a secret that you can decrypt. This ensures the details haven't been faked or tampered with.
Rather than creating a Composite App you can create a Canvas App. This is a type of Connected App. You can find instructions for setting this up at Creating a Connected App. The Signed Request is POSTed to your web app. See Signed Request Authentication
I have configured my first application in Windows Azure Active Directory and everything works fine: I can login using accounts in my directory.
However, I'm not entirely clear on all the concepts yet, especially the sign-on url. The tooltip says:
The URL where users can sign in and use your app. You can change this later.
But users sign in somewhere on login.windows.net and furthermore, it doesn't matter what I enter here, authentication keeps working. So what is this 'sign-on url'?
If you visit http://aka.ms/myapps, you'll find a long list of applications that have access to your account. If you click on these apps, you should be redirected to a home page where the sign-in process could be initialized. However, if the app doesn't declare a signInUrl in its manifest, you'll get an error that says the app is misconfigured.
something went wrong...
You cannot access this application because it has been misconfigured. Contact your IT department and include the following information:
Undefined Sign-On URL for application "BlahBlahBlah"
In the new Azure portal UI, the "SIGN-ON URL" is now called "Home page URL", which you can find under Branding in the app registration configuration.
I can see why this may be confusing. I think you can look at this as the URL where the whole sign-in process starts (i.e. your app's URL, which, if they're not logged in, will sends them to login.windows.net).
Also, even if for now you might be able to enter anything and authentication still works, I'd try to make it point to the right place just in case things change in the future.
It appears to me that It has significance with respect to wsFederation realm value when user sign out and redirected to Active directory sign in page.
When you add your application to azure ad, it gives you client id and key. When you use that in MVC webappp, you will see that there is an entry like below in web.config:
<system.identityModel.services>
<federationConfiguration>
<cookieHandler requireSsl="true" />
<wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/{some guid}/wsfed" realm="https://localhost:44304/" requireHttps="true" />
</federationConfiguration>
</system.identityModel.services>
Copy the value of user to sign-on url.
I would like to use Oauth 2 for an application in Google App Engine with Java, but I dont find any good example of that use, I would be very thankful if somebody could help me please, it is something frustrating dont find good examples, thnak you.
My 2c is avoid oauth2 libraries. Of course opinions may vary, but for me they provide very leaky abstractions, so you end up being dragged into understanding oauth by the back door. For me at least, taking an hour to read the the two pages that tell you all you need to know, and carefully avoiding all the others, will get you where you want to be.
In simple terms, the steps are :-
Call the auth URL with your app/client ID and the scopes you require. Include the "email" scope.
Google will walk the user through login, and (if the first time through) authorisation dialogues
Eventually the browser will redirect back to your oauthcallback url, and pass you an auth code
Call google to convert the auth code to a refresh token. This will also return the user's google ID and an access token.
Store the user ID in your session so you can identify the user subsequently
Persist the refresh token alongside the google user id in a database
On subsequent visits...
If you have the google user id in the your session, you can retrieve the refresh token from your database and use it to generate access tokens as you need them.
If you do NOT have the google user id in your session, go through the steps above. This time, google will NOT prompt the user for authorisation (since it's already authorised), and the refresh token will be blank (since you already have one stored).
Everything you need to know is within the oauth playground page. If you click through the buttons, you will see that it is following the steps I outlined above.
You then need to deal with the possible error situations, eg
user declines permission
user withdraws permission
google expired the refresh token (happens a lot) so you need to re-auth
timeouts
The two pages you need to read are :-
https://developers.google.com/accounts/docs/OAuth2WebServer and the oauth playground at https://developers.google.com/oauthplayground/
Trust me, as long as you know how to form a URL, store a refresh token (it's just a string) and parse a JSON response, then everything you need is on those pages. Except ...
all the documentation skips over the need to preserve the user ID in your session so you know who it is that is accessing your app. If you're on AppEngine, you may be confused by the appengine sample code which uses a separate appengine login. Ignore it. You will be using oauth to authenticate the user so the appengine stuff doesn't apply and is somewhat confusing.
It's actually much simpler than some of the documentation would lead you to believe, and like I said, imho the leaky libraries don't help.
I'm trying to do exactly the same thing and I agree - it is extremely hard to find a good example of this.
I did find this youtube video however and I think it would help: https://www.youtube.com/watch?v=tVIIgcIqoPw.
Its from Google and it is called Getting Started with Google APIs. The last segment of the video deals with authentication.
There are several OAuth 2 client and server libraries for Java listed on this page: http://oauth.net/2/
Here's quick-start documentation for using Apache Otlu: https://cwiki.apache.org/confluence/display/OLTU/OAuth+2.0+Client+Quickstart
If you're accessing a Google API (as a client), you can use the Google client library for Java, which does OAuth as well as API set-up: https://code.google.com/p/google-api-java-client/
I am working on a chrome bookmarking extension with google app engine as the backend. I am the only user now but I thought that if in the future there are other users the url needs to include the user name for the extension to interact with the backend. So I was thinking to change
http://ting-1.appspot.com/useradminpage
to
http://ting-1.appspot.com/user_name/useradminpage
where "user_name" is the gmail user id.
But I looked at twitter url and I see that they have
http://twitter.com/#!/user_name/
What is the purpose of "#!"? Is my scheme good enough in this case?
The # in a URL signifies the 'fragment identifier'. Historically this has been used to identify a part of a document identified by an 'anchor' tag, but recently webapp developers have begun to use it to pass information about the page state to Javascript code running in the page. This is used because it's possible for Javascript code to modify the fragment of the current page without causing the page to reload - meaning it can update as you browse through the webapp, and go right back to where you were when you reload the page.
The fragment is not sent to the server when the browser loads a page, so Twitter's server just sees a request for twitter.com; it's up to the Javascript code in the page to examine the fragment and determine what to do after that.
In your particular case, assuming you're using the App Engine User service to authenticate users, you have a number of options for how to distinguish users in your URLs:
Use their email address. In theory this can change, and users may not want their address in a URL they will share. If the URLs are private, this is more or less a moot point.
Use their user_id. This is opaque and reveals no useful information about the user, so it's safe, but it's also meaningless and hard to remember.
Let users pick a nickname for their URLs, like Facebook and other services do, on a first-in, first-served basis.