I would like to be able to authenticate via OpenID/mobile app on a MDM enrolled device, without user having to login ( as with a classical hybrid pkce flow ),
I mean , the device is enroled on MDM so I would like to authenticate against identity server and find some way to used some mdm pushed infos on the device to be able to bypass the user interaction.
but I'm not able to find some advices or articles in order to be able to do that on a minimal safe way.
Is somebody maybe could give an advice or somewhere to look , I'm quite lost to be honest.
Thks !
Related
I'm trying to understand how to monetize GDS connectors once are publicated in the community. Does something know how to do it. I can't find a clue on this on the URL: https://developers.google.com/datastudio/connector/get-started
Monetization is entirely upto the developer. You will need to implement your own payment and verification for this.
You can verify the user identify and level of access through either your own 3P authentication for the connector OR by calling your own API with the effective user's email address.
We're are about to build a new intranet system for our company, leaving SharePoint behind. The system will be built using Ruby on Rails. Since we're using Office365 for mail, calendar etc., we would like to authenticate our intranet users through Office365.
I'm aware of Microsoft Graph API, but I have a hard time figuring out of there is a possibility to authenticate users from a third-party application. Moreover, we would like to retrieve general information about the user, like profile picture and calendar information.
Is anybody knowledgeable about Microsoft Graph API and know if it's possible to achieve our goals using the API?
You're on the right track. You would authenticate with Azure AD, which is in the 365 ecosystem.
I wrote (and answered) a detailed guide here:
How to get the JWT (using OpenIdConnect) from HttpContext, and pass to Azure AD Graph API
Note that this is the OpenIdConnect flow. I think the Saml2 flow is somewhat different.
Don't take my advice on storing the authentication codes or try to acquire the token silently - it ended up causing issues in production that weren't seen in test. Rather, just use the user object id as your key attribute.
The microsoft documentation on the topic is a little cerebral and abstract, so it'll take a little head scratching, but have a look at the samples mentioned in the post I linked above, they'll get you started.
Yes, using Microsoft Graph is the right way to go about achieving the stated goals here.
There are quiet a few samples and tutorials provided on the Microsoft identity platform code samples page that will teach how to build an app that calls Microsoft Graph.
I've researched a ton and can't seem to find a solution for how to limit access to a secure mobile website to ONLY PREVIOUSLY REGISTERED devices.
I already have a secure login in-place, but we must also insure that ONLY registered devices access the site. We cannot have users sharing login information with others and allowing others to login and use the protected information.
Is there anyway to do this?
I've looked at trying to acquire the devices MAC address using JavaScript, PHP, or something similar, but this doesn't seem to be an option.
MAC addresses can be spoofed, so use something else such as REST-based authentication.
You can't do that because websites usually register users as opposed to their mobile devices as nothing can be truly unique about a physical device but the information it carries. The proper way of doing client based (as opposed to user based) authentication is to use a client certificate.
If you just want to simplify the sign-in experience for your users on mobile device you may want to take a look at this.
Looking at the Google App Engine API, it seems that despite all its great features, the User API is extremely limiting. It seems you can only authenticate people who have a Google account, or use an OpenID account, or via some OAuth kung fu (handshaking with a Facebook account etc).
This appears to be a major stumbling block for anyone who wants a proprietary user base by creating user accounts within the application. In short, I don't want my users to have to use or create a Google account to access my app.
Has anyone else come across this limitation and has it been a deal breaker for using the GAE? Am I missing something? It is possible to deploy my own Spring based security etc within the app and use my own User API? Comments on this issue greatly appreciated. Thanks.
You're free to completely ignore the Users API and implement your own authentication system, as you would in any other hosting environment. Nothing about App Engine prevents you from doing so.
The Users API is just there as a convenience, in case you'd like to spare yourself the effort of re-implementing everything, and spare your users the inconvenience of filling out another sign up form and remembering another set of credentials.
You can always implement your own user management system.
In my application I have used spring-security for this purpose. spring security 3.0.1 works perfectly fine with app engine 1.3.5. There may occur some issues integrating other versions of both. I found below links extremely useful :
http://www.google-app-engine.com/blog/post/Spring-security-fix-for-google-app-engine.aspx.
http://www.dotnetguru2.org/bmarchesson/index.php?p=1100
http://groups.google.com/group/google-appengine-java/browse_thread/thread/964e7f5e42840d9c
I am still trying to wrap my mind around the workings of OAuth/OpenID, as such...
I am developing an "installed app" that will run on computers and iPhone. A given user may install the client app on multiple machines, and all of the user's installed clients will synchronize via a centralized Google App Engine service. The GAE service will also allow multiple users to collaborate on the data produced by the installed app, via a web app.
I don't want to roll my own authentication system, for my own ease and also to spare users from yet another set of credentials. As such I was initially thinking of using Google's clientlogin service, but then I thought OAuth/OpenID would be better because it would allow users to use not just Google credentials but also credentials from the other OpenID providers. Also, avoiding asking the user for a login/password seems more secure.
My question is... I'm not sure if this is the right use case for OAuth/OpenID. I am not accessing data from any other service, I am just looking for an authentication solution. Also, how difficult is this scenario to accomplish using Google App Engine (java)?
Any advice and/or starting points would be much appreciated!
My question is... I'm not sure if this is the right use case for OAuth/OpenID.
The "use case" for oAuth is: App X requires access to App Y. App X "asks" permission for access to App Y through your credentials. App X received an "authorized access token".
In your case, assuming I understood correctly, you could have the App on GAE implement an OpenID consumer and have your mobile app access the GAE app through oAuth.
In other words, your approach seems like a sensible one.