I am trying to validate a SAML token that was created by our WIF-based custom STS inside a REST web service.
There are a couple of functions to do validation. One is SecurityTokenHandlerCollection.ValidateToken() and another is SamlSecurityTokenAuthenticator.ValidateToken().
Unfortunately the online Microsoft MSDN help for these classes and functions is worthless and does not describe at all what it is these functions are doing.
What are these functions validating and how are they doing it? What are the differences between them? Are they automatically looking up the certificate in the Windows Certificate Store to check the signature of the token, and validating the encrypted credentials object? Because I don't pass a certificate name in anywhere. Or are there other manual operations I need to do myself to validate the token?
I realize one returns a ClaimsIdentityCollection and the other returns a collection of IAuthorizationPolicy objects. But is that the only difference? I can't tell.
I can find plenty of information out on the web about the STS and claims and even validating claims, which I am doing successfully, but I can hardly find any information on validating the token itself to make sure it is one I created.
In most cases you don't need to worry about the token validation details. All this is taken care for you by WIF.
But if you really want to know, the best source of information is Vittorio's book: http://www.amazon.com/Programming-Windows%C2%AE-Identity-Foundation-Dev/dp/0735627185
There are some details here: http://msdn.microsoft.com/en-us/library/ff359114.aspx
Another good way of learning is by looking at the extensions built to handle non-SAML tokens (e.g SWT). Download the samples here and look for the REST services.
Related
I understand the mechanism of OIDC in Kogito with the help of process-usertasks-with-security-oidc-quarkus example.
However, I have a question about user information. In the given example, the approved field is filled by a Query string. Is there any way to get user information in Kogito? If it doesn't have that feature, can it reflect from header to service?
The integration with the security context inside the Kogito app is something that is on the radar, see https://issues.redhat.com/browse/KOGITO-6162. That would ignore the query string and use the authenticated user. Perhaps, for now, you could create your own endpoint to retrieve the authenticated information as needed and mimic the same API call that is done in the generated endpoint.
I figure out a temporary fix that problem with help of written Custom Service when using Kogito with Quarkus.
https://quarkus.io/guides/security-jwt
JWT Injection can call from the Service layer when used with Kogito.
It is also possible to propagate user identity to other workflow items with internally tagged process variables.
I am working on a project which needs User Authentication. The "Clients" are iOS (Swift) or Android (Kotlin) native applications. The original form of the API (NodeJS) used Facebook and Account Kit for OAuth and Phone authentication respectively. Since Account Kit shutdown, we moved to Firebase Phone Authentication for Phone but left Facebook in its original form. Now, we're wanting to consolidate our Authentication providers (to Firebase) but I can't seem to find a way to "convert" or "import" Facebook users to Firebase-based Facebook users.
So far, I've read through the Documentation, including the category about importing users, but it doesn't seem to indicate an ability to maintain backwards compatibility, while also moving forward to Firebase. What I mean is, it has an ability to set information, but it doesn't indicate that the same information will be used to authenticate that user as the same unique visitor.
What I am looking for is either transitory logic, which will handle this during login, or preferably, a "bulk-insert" type migration. Essentially, I want to have it setup so that the API only needs to keep a single authentication UID, and use only a single third party (even if they then use another subsequent third party) while maintaining user uniqueness (so that it doesn't create a new user for the same Facebook account).
Part of my problem in creating a temporary patch (not necessary if the main question is answered) is that I don't know of a way to differentiate between a Facebook UID and a Firebase UID to fork the logic. Again, this is only relevant if there isn't a solution for migration.
Feel free to request any more details that would be useful.
Update #1
I realized my question was open ended in what I was asking. I've been digging further and can better define my question:
I need a way to bulk insert users into Firebase's Authentication with a provider of Facebook. I know I can import them, via admin.auth().importUsers([...]) and that I can create accounts via admin.auth().createUser({...}) but when I do the former I can't seem to get back the user's UID, and the latter doesn't seem to allow specifying a provider. Am I missing something?
For example, Is it possible to have the native subscription based authentication and OAuth2 such that either one of these can be used for authenticating any given request?
At present, I have subscription based approach on the API frontend, but am interested in moving to OAuth. Id like to however keep clients who have been configured to use the subscription based approach unchanged if possible.
perhaps the answer is that , I must stick to 1 and only 1.
But feel this is worthwhile to ask since perhaps others may start with subscription based approach, and interested in moving towards an alternative.
Once solution I feel might be to create a seperate API front end for OAuth2, which points to same backend. That would satisfy the problem. However, Im hoping to keep the same api frontend. If that makes sense.
I don't think it's possible since if you won't pass the subscription key or pass an invalid one it will deny the request.
What you can do is use versions, so let's say v1 uses subscription key and v2 uses another authentication mechanism. So in summary, you'll duplicate all API's, but for v2 you won't assign a Product (won't require the subscription key).
I want to make an option such that I can issue 3rd part developers access to my data and to do so, similar to the following: https://docs.sharedcount.com/, I want to create a system wherein those developers are provided an API key for which the consumption count can be monitored
Came through Waterlock but does not look like it has this feature: http://waterlock.ninja/
Curious, what would be the best approach to implement API keywords for a Sail.js app?
Sails makes this incredibly easy by use of policies. When a user signs up, assign them an API key, and then create a policy that checks the params for a valid API key -- i.e. req.param('APIKey') -- and deny access if one is not found.
I have an Open ID based authentication system on my site.
Occasionally users will have an account registered under foo#gmail.com and they will attempt to login using the google open id provider https://www.google.com/accounts/o8/id, in this case I would like to automatically associate the account and log them in.
When the process is done I get a payload from somewhere claiming that openid.op_endpoint=https://www.google.com/accounts/o8/id.
My question:
Can I trust openid.op_endpoint to be correct? Can this be spoofed somehow by a malicious openid provider?
For illustration, lets say someone types in http://evil.org as their openid provider, can I somehow end up getting a request back that claims openid.op_endpoint is google? Do I need to store extra information against the nonce to validate?
The spec is kind of tricky to understand
Yes and no. No you shouldn't trust anything you get over the wire, including openid.op_endpoint. But if you are using a secure OpenID library, this parameter is verified before the user is ever allowed to log into your site. The OpenID spec does, in fact must, provide a way for this and other parameters to be verified and without verification the authentication protocol is worse than useless.
So, make sure your library is decent. Then yes, trust the openid.op_endpoint parameter. But not the one you get from the query string yourself, since OpenID messages can be POSTed to you, and the parameter would not show up in the query string. Worse, if you were to check the query string in this case, you'd probably be opening yourself up to a security hole where an attacker could add that parameter to the querystring and fool you while complying with the library's requirements. So it's best to use the API the library exposes to find out what the OP endpoint is.
As far as linking the accounts in this way, this is a good approach since Google will only send email addresses it knows are truly controlled by the user. If you've already required your user to go through an email verification step, then linking the account is safe. But if the email address you have for the user wasn't ever verified, then you must not link the accounts based on this match or I can hijack someone else's account by creating an account that has someone else's email address, and then wait for them to log in using OpenID and now I can get into their account.