Am developing a Windows Store 8.1 app using C# and xaml.
I am doing Single sign on using Azure Active Directory Account login.
I do not want users to be redirected to the Microsoft Account login screen, and then come back. I want to supply them with the login credential screen where we capture their username and password, and then we want to programatically do the authentication against Azure AD, and get back the claims identity.
How can i achieve this?
This is not a supported scenario for security concerns. One of the value propositions for AAD is that the password management, across the whole login lifecycle, is managed and secure. This is particularly important for scenarios in which AAD is securing a 3rd-party SaaS solution. A developer should not be able to have access to a user's credentials at any point.
All that said, it sounds like there is another question here which is answerable: How can I customize the login screen that AAD gives me?
AAD Premium does offer features for adding custom branding to your tenant. However, you still will be working with a screen that is provided for you.
Related
I have this website where Bank users register using API and then Bank can use our SSO login API to log their users directly from Bank's mobile App or website. Now the Bank wants to log into our website via Banno's OAuth. Such that users log into Banno via Bank and then login directly into our website.
How can this be achieved? How will banno know which user to login? How to make it without having users to come into our website and fill user's login details? Can anyone help?
It sounds like your scenario is looking for Banno to be the 'Identity Provider' which is supported by our OAuth + OpenID Connection implementation in our Authentication Framework.
It'll be a good idea to take a look at the Consumer API OpenID Connect Example for inspiration.
When you run that example project, you can navigate in your web browser to https://localhost:8080/login.html. That'll show a page with a "Sign in with Banno" button. The page is meant to be a generic representation of what a non-Jack Henry web page would be.
Imagine that the button was formatted to say "Sign in with [Financial-Institution-name-goes-here]", it would be the same concept.
When you click the "Sign in with Banno" button, you'll be redirected to the Garden demo institution. This happens because the example project is configured to begin the authorization flow and use Garden.
If you're not signed in as your user in Garden, you'll be prompted to sign in.
It's worth noting that the username + password are never shared back to the example project...the user is logging into their (Banno-powered) financial institution.
After signing in (and accepting the permissions which have been requested), your web browser will be redirected to https://localhost:8080/me which finishes the authentication flow.
That page then displays the Identity Token for your convenience as a developer.
The content of the Identity Token is usable to cross-reference the user to your existing system and/or to prefill out registration forms.
Hope this helps!
I have a working implementation of SAML (OneLogin) within an enterprise architecture.
When a guest user arrives at my application they are redirected to the company login where they enter their username / password. After that the user identity is passed back to my application and we log them in.
However, I notice that in other applications within the company I do not have to login at all. Somehow the website "knows who I am" and seems to authenticate me automatically. I presume there is some form of certificate on my pc / browser which the other applications are passing to the SAML??
Can somebody tell me the technical term or process? Is there a process whereby I simply pull the certificate from the browser or PC and pass it to the SAML? I would like my users to be able to auto-login without entering their credentials.
Thanks
There's a number of mechanisms that support an "automatic" authentication like what you describe. In the Identity and Access Management (IAM) realm, we have all sorts of names for it, but many of us call that "seamless single sign-on (SSO)".
Within a corporate environment, I would suspect that you are dealing with a one of two mechanisms: Kerberos authentication (especially if you're a Microsoft shop and log in to a domain-joined machine on a daily basis), or your machine is in an MDM-type of system, which uses a machine- and/or user-based certificate (aka PKI) to authenticate the user or user/machine combination.
Within your enterprise, if there are other applications whose users are immediately authenticated to the application without entering their username and password, then you should talk to your IAM team or your Single Sign On (SSO) administrators to understand why that doesn't work for yours.
I will also say that it's possible that your security team evaluated what information your application offers (insider financials? source code? your secret recipe? credit card data?) and decided that they would still require the user enter their username and password to get access to the data. So when you go to your SSO admins to ask, if they say that it's intentional, you should feel free to ask why and who you should talk to about it.
After a LOT of research and testing I finally have the answer to this question, and it is incredibly simple!
In summary:
I have a working solution with OneLogin that sends me to a page like this:
https://sts.companyname.com/adfs/ls
The url is specified in the config: saml->config->idp->singleSignOnService->url
However, this page requires the user to enter their username and password and, instead, I would like the system to be fully seamless.
The solution, it turns out, is simply to hyperlink to the following url:
https://sts.companyname.com/adfs/ls/IdpInitiatedSignon.aspx?LoginToRp=https://mypage.com/saml/metadata
where "loginToRp" url is the url provided in saml->config->sp->entityID
The ADFS IDP Initiated Signon will connect to your metadata schema and automatically log the user in (without the user needing to provide any credentials)
NOTE: this only applies to intranet sites in a corporate environment
Google offers two systems for accessing Gmail. IMAP and SMTP and a the Gmail rest api Gmail - Scope for SMTP is https://mail.google.com/. However with Gmail rest API, just the required scope (like send, modify) can be used.
What are the main differences between the implementation of these two for sending an email? I've been using SMTP to send the mails without any issues but since that involves having a bigger scope for OAuth2, I want to know if there are any possible risks involved in moving to the API approach.
Users.messages: send says there's a restriction on attachment size.
This method supports an /upload URI and accepts uploaded media with
the following characteristics:
Maximum file size: 35MB Accepted Media MIME types: message/rfc822
Are there any other differences that I should know about if I start using Gmail APIs instead of using SMTP connection for OAuth2.
Also, what is the reasoning behind providing full access as the only possible scope for SMTP/IMAP?
Note: I only requirement is the ability to send emails.
Using SMTP you are directly accessing the mail server located at mail.google.com. SMTP servers have been around since the 60's they don't have the ability to limit what access you have. When you log in you have full access to do what ever the mail server in question is capable of. To login to the SMTP server you need the login (most often email address) and password of the account you wish to access. Drawback to using the SMTP to connect to Gmail is that if the user changed the password you would then loose access. This day in age it is also considered by most to be bad practice for third party developers to be storing a users login and password in your system. For example: I would never give any application access to my login and password to Google. How could you ever prove to me that your system is secure? If your hacked so am I.
Now on to Oauth2. Oauth came about sometime around 2005 when people wanted to be able to access APIs without having to do something stupid like
http://awsom.api.com?login=xxx&password=XXX
If memory services it was originally created for the twitter API developers wanted to be able to access their users twitter account without having to store their login in and password. Again the main problem with this was the developer in question would then have full access to a users twitter account and if the user or the developer changed the password things would break.
So they created OAuth. The main features with OAuth are:
You can limit access you give an application: (readonly, read write)
Password change does not affect access
No sharing account credentials with developers of third party apps
So the main point for me as a developer using Oauth with any Google API would be not having to store the login and password of my users and not being affected by a password change. My users would probably say not having to share their login with me and being able to give my application limited access to their account.
Now back to Gmail. Google made a change about two months ago any refresh token(oauth2) that was created using a Gmail scope will automatically expire when the user changes their password. To my knowledge this is only Gmail. so that removes point number two from the features of oauth.
Which should you use is really up to you, assuming you need to be able to send emails. Then limiting access to read only in your application isn't something you need (point one). However in my opinion from a security standpoint I would never ask my users to give me their login and password and would always choose oauth2. Yes SMTP works, will Google shut it down, probably not users have always been given access to the direct SMTP server of their email provider its how applications like outlook work.
as for OAuth support with SMTP unfortunately I haven't done much research into that guess I need to read RFC 4422 . If you can use OAuth with SMTP servers then again I guess the question would have to come down to speed is it faster to access the SMTP server or the REST API server? I can really think of no differences. Attachments with the Rest API can be tricky. I may do a bit more digging on the subject.
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.
I am developing windows phone-8 app In this I need to register e-mail and password and after I have to login with registered user-name and password.I am using HttpWebRequest Class but don't know how it is possible please share with me any info or link regarding that.
You don't even need a separate web server running an auth service. Instead, you could use Windows Azure Mobile Services. There are several reasons for that, the main being the fact that you can easily manage outgoing data (register users) and check for existing data (authenticating users).
You can use the Azure Mobile Services client if you need an abstracted out data access layer.