Is it possible for my server to get credentials for a user without their username and password in order to send it back to the client?
I have another means of authentication and I think this would be easier to do this rather than trying to store tokens in a database where they will expire.
Yes. You can provide alternatives to Username/Password to login a user. Developer Authenticated Identities Authflow let your server take the place of the user pool or other social identity provider.
User Pools are just that, an AWS hosted authentication tool. They let users prove they own a specific login string (email, phone, etc.) by providing a password. Then that user is mapped to an Identity in an Identity Pool.
You can also use Facebook as the "proof" and get an Identity ID that way. If you pass both (User pool and Facebook) tokens to the Identity pool at the same time you will link those two login ID under one Identity ID. Now you can log in using either method and the app will treat you as the same person because you have the same Identity ID.
You can implement a server which will let you act as that same type of provider so that users can prove to your server they are who they say they are then you can signal to the Identity pool that they are "X" person.
The thing to remember is that the User pool is used to store and validate username/password combos (and some other attributes if you want). The Identity pool is used to map 1 or more logins (Facebook, Google, User Pool, etc) to an Identity Id that your app(s) can use to identify/differentiate users.
No you would have to either, at least authenticate once with Cognito (afterwards use refresh tokens to obtain new id/access tokens without having to enter username/password) or federate with another Identity Provider (but you would still have to authenticate with that identity provider).
Related
There's new feature in aws cognito to allow user to sign in through external federation identity providers in user pool.
I followed the steps given the aws Doc.
1) select identity providers
2) attributes mapping
But when I sign up, fb/ Google account ID don't get map in user pool.
Can someone give me a proper code to do this. I mean how should I map fb/ Google user sign in programmatically in cognito user pool.
Currently, only the Facebook id, Google sub, and Login with Amazon user_id attributes can be mapped to the Amazon Cognito user pools username attribute.
What does your attribute mapping look like?
When using CAS Surrogate Authentication as per:
https://apereo.github.io/cas/5.1.x/installation/Surrogate-Authentication.html
is it possible to retrieve the identifier of the primary (admin) user in the application which they're being logged into?
This is for the purpose of logging both the identifier of the impersonated user and the admin user who is performing the action on behalf of the user.
Yes, in the final validation response both attributes are returned that represent the impersonated user as well as the "admin/real" user. Both are also sent to the audit log.
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.
Bear with me please. I am a layman in web technology and have few simple questions which need simple language answers.
When we login using a username and password on any website, what exact connection/relation is established with the website server? Is it that the server stores the IP address of the user and allows the user access to certain tables from the server database for a short span of time and the regular query to the server keeps the 'connection alive'?
Thanks in advance..
A login system receives a set of credentials from the user, typically an identifier and a password. It could include what is called an authentication token, which is either generated by a handheld device (so you not only have to have id and password but the token generator; it's on the equivalent of requiring both the pin and the card at an ATM), or it's generated by combining the password with something else and returning an encryption result.
The login system, once it receives the credentials, compares them to what is stored on the credential database. In some cases the credentials are sent encrypted, such that even the login system doesn't even know what they are, all it does is determine if the encryption is correct. This would mean that even if someone was monitoring the communication channel they could not use it to fake a login later.
Now, if the credential is valid, one of two things happens. For a desktop application or general sign-on, the login program will transfer control to either the rest of the program (for an application), or grants access to the system (for a sign on). When the person leaves the application or signs off the system, then everything starts over.
For a website, the login program will send the user a cookie that another part of the website can read and determine the user was authenticated and their credentials passed. This continues until the cookie expires, or the user logs out. If the user logs out, the website sends a new cookie that says the former cookie is expired.
I have an iPhone application that needs to collect data from an online MySQL database. I've written a PHP web service so I collect the data with JSON. The problem is that everyone can see the data if they go to the URL now. How do i secure the data transfer properly?
Thanks for your suggestions.
Typically, if you are showing data private to a particular user, then each user will generally have an account (user id and password). The app will pass the user's credentials to the server before the server will provide the user's data.
You can also do something similar using SSO integration, or OAuth (ala Facebook).
In some cases, your app may only pass the username/password on the initial call and receive a session ID, which the app passes on remaining calls. This allows the server to store session data.
Even if the data isn't private to a particular user, you can use accounts to restrict access and privileges for a publicly reachable web API.
In all of the above cases encryption such as SSL (HTTPS) must be used to protect the authentication mechanisms and data transfer.
I'm assuming your data is public for all users of your app, in other words, you don't want to implement a login mechanism for your users. If you just want to make sure you return the data only to users of your app and not to anyone who happens to enter the right URL in their browser, you will need to sign your requests, so that only requests from your app are accepted by your server.
I use a secret key that my app uses to create a hash/digest of the request which the server verifies (it knows the secret key as well). Also I make sure requests cannot be replayed if they are intercepted by adding a timestamp and a nonce. The timestamp is checked to be within 10 minutes of the server's timestamp (relaxed sync) and the nonce must be unique (server keeps the last 10 minutes of nonces). This way no-one can copy the same request, the server will just serve an error if they try.
This post explains how to sign your requests in a bit more detail:
http://www.naildrivin5.com/blog/2008/04/21/rest-security-signing-requests-with-secret-key-but-does-it-work.html