We want to provide seamless access for all our users to SP's like publishers. The SP's are independent and provide services to a lot of different companies, i.e., we each have independent IdP solutions.
We want it to work as if there were no authentication, i.e., the user find a link on the Internet and follow it. If the site provide special services (that we pay for) for our users we would like them to use our own IdP (but only for our own users) to authenticate them.
Our current SAML setup requires that the SP support IP-address recognition and/or use specific domain names, i.e., the user access a specific domain name or come from our IP-ranges so the SP knows which IdP to redirect to but if our user comes from any other IP-address and don't access a specific URL the system is lost.
How is this solved?
I think a cookie given by the SP every time the user gets authenticated (from our network which the SP recognizes) can solve this but is that the standard? And it is not really a solution as it requires that our users have visited them at least once from our network!
This isn't so much a SAML question as it is an identity provider discovery problem which isn't specific to the protocol. How is a publisher supposed to know / decide that a particular user should be redirected to your IdP via SAML or any other protocol? This isn't a tractable problem in a general sense. The publisher and you will need to agree on a contract between two entities (you and these publishers) when it comes to these special users / services.
One possible implementation of IdP discovery that doesn't involve domains or IP ranges is a dynamic lookup of the IdP based on the user's identity. User clicks a link, navigates to the publisher site and attempts to login with (for example) his identity of myname#mycompany.com . The publisher can then do a lookup of mycompany.com in their identity store of special users / services / IdPs and determine that this user should not be allowed to login with local (publisher-managed) credentials. Instead, the user should be sent to some 3rd party IdP via a SAML authentication request. The publisher can do this at the time of user login but before the user has a chance to enter their publisher-managed credentials, be it via your favorite AJAX technique or some other form of UI gratification.
The publisher could use a persistent cookie so that the next time this user comes to this publisher they'll know that this user "belongs" to a 3rd party IdP and redirect accordingly.
Related
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
Some pages, such as amazon and Gmail, separate out the HTML Input fields for E-Mail and Password onto two different HTML pages, one after another.
What is the rationale for this approach instead of asking for credentials on just a single page with one HTML Form that has two Input fields at the same time?
Most of the times this happens with federated identity, when multiple identity providers can actually log you in. For example you can use your company identity provider (ie. login server) to log onto a 3rd party resource which trusts your company IdP.
But the question is then how you choose which provider to use in the 3rd party, if they accept several. And this is one solution: you enter your email address, and your email is associated with your IdP, so you can be redirected to the correct login page (from where you will be redirected back). Of course, your IdP can easily be the site itself, in which case the process looks rather silly.
Note that you can be redirected to the "local" password page regardless of whether your username is actually correct or not, and usually only the domain part of the email is used to decide where to redirect, so it is less of a security issue, user enumeration is still not possible. But you can try and enumerate valid identity providers.
I am using EWS managed API to implement notification subscription with exchange server. So, I am trying to figure out if I can assume that the autodiscovery url for users within the same domain will be same?
Yes
Autodiscover is used to get necessary information on how to connect to the exchange server by itself, with minimal user input required. It does so by taking the domain from the users e-mail address and is testing various standard EWS Exchange-Endpoints with it.
An example:
"https://" + domain + "/autodiscover/autodiscover" + fileExtension
Because users within the same domain communicate with the same exchange server, the AutodiscoverURL stays the same for all of them.
You should be using Autodiscover to work out the endpoint for ever user unless you have a very simple network topology (eg one server etc) so making that assumption woudn't be best practice. The URL that Autodiscover will return can be different for a number of reasons eg different Internal and External exchange configuration https://technet.microsoft.com/en-us/library/hh529912(v=exchg.150).aspx (so depending on the client location). Also if your using notifications on Exchange 2013 and up for multiple users then you should be using Autodiscover to get the grouping information for the users https://msdn.microsoft.com/en-us/library/office/dn458789(v=exchg.150).aspx so you can maintain affinity correctly.
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.
CAS can push the logged in user attributes to the client when using the SAML ticket validation. But if I use OAuth, is there another way that I can retrieve user attributes through a second call to the CAS server using the received accessToken? I think this should be possible as when a user is authenticated(eg. through facebook) the requested attributes are in CAS memory.
Yes, it's possible as the user's attributes are indeed stored in the CAS server. As explained in the documentation: https://wiki.jasig.org/display/CASUM/Configuration+for+the+OAuth+client+support+in+CAS+server+version+%3E%3D+3.5.1, you can define what OAuth attributes you want to retrieve exactly like for any other attribute repository. You can even recreate the user's profile on the CAS client application side.
Here is a working example: https://github.com/leleuj/cas-oauth-demo-3.5.x/blob/master/cas-oauth-client-demo-3.5.x/src/main/webapp/WEB-INF/deployerConfigContext.xml. You can also get the OAuth access token to perform additionnal operations...