We are bringing on a new temporary developer to help out with a project and I've been asked about installing libraries to store the SMTP login credentials to our dontreply#xyz.com email so that the developer can set up web forms without access to the credentials as this would require us to change the credentials for all out forms after the developer finishes her contract.
I've searched and found nothing, the closest thing was someone stating that you should create a company account instead of using personal account on this post: PHPMailer Hide SMTP Authentication?
can anyone help with me with this or point me in the right direction at least?
Thanks
Like that question says, there's not much you can do to prevent the dev getting hold of the credentials. Even OAuth won't help. This isn't a PHPMailer question, or even a PHP question really - it's about configuration management, and the same problems occur in pretty much all languages.
It may be solveable at a different level though - One option might be to wall off direct access using a mail proxy / relay. Configure a nearby/local mail server that you can submit to freely, and have that deal with real outbound, including relaying through your mail account. That way the developer can send through your chosen server without needing any direct access at all. It might make their life a little more difficult, but it solves your main problem.
Related
Im trying to make a little .core service to keep gitlab issue's and a board on Microsoft Planner in sync.
Gitlab side isn't an issue however talking to the planner aspect is proving problematic.
In Azure I have successfully added an App Registration and using the delegated permissions, I can do what I need, BUT when it gets the access token, I get the old
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code ******** to authenticate.
Which as im trying to make this into a service, isn't great.
I then setup permission as a deamon but Planner dosn't allow assess to 'Application Permissions' which planner needs.
So is there another option?
Unfortunately Planner does not support Application Permissions. You can try to use a user account specifically created to act as your service as a workaround. There is currently no timeline for Planner supporting Application Permissions, however this is in our work backlog.
For example if you create a new Plannerplan then it works only with delegated permissions. It's not exposed with application permissions so that you can use it in daemon app. Unfortunately this is by design or in other words, it will work only with delegated permissions only at this point.
Unfortunately it won't work that way, but you may want to give a try. Being said that i would suggest you to file an Microsoft Uservoice or upvote an existing uservoice item talks about it - so that they can consider implementing it as a feature which support application permissions
Also you can see above #Tarkan confirmed the same and shared insight that its in their backlog too.
My newest task is going to be to implement automatic update of a licence:
The program detects that the licence is expired or about to expire and offers the user to automatically upate this. So far so good. Now what is needed:
The program sends the user's credentials to a win 2008 server over the internet.
The server checks the credentials and if they are OK generates a licence file that is sent back.
How to implement these steps? I consider using WCF, with which I have some experience.
The transfer mechanism isn't the issue. WCF should work fine. You could use SSL and/or WCF Security.
The inherent security of the credentials and license is the concern. Remember, anyone can call the service and former clients have access to expired license files. People may try to cheat the system. Ask yourself questions such as:
Can person A figure out what person B's credentials are and request a license as person B?
Can a person reverse-engineer a license file and extend its life?
See for instance Need advice to design 'crack-proof' software (and numerous other SO posts on licensing).
I have REST services that I was planning on protecting with Windows Integrated Authentication (NTLM), as it should only be accessible to those internal to the company, and it will end up being on a website that is accessible by the public.
But, then I thought about mobile applications and I realized that Android, for example, won't be able to pass the credentials needed, so now I am stuck on how to protect it.
This is written in WCF 4.0, and my thought was to get the credentials, then determine who the user is and then check if they can use the GET request and see the data.
I don't want to force the user to pass passwords, as this will then be in the IIS log, and so is a security hole.
My present concern is for the GET request, as POST will be handled by the same method I expect.
One solution, which I don't think is a good option, would be to have them log into Sharepoint, then accept only forwarded reqests from Sharepoint.
Another approach would be to put my SSO solution in front of these services, which would then force people to log in if they don't have credentials, so the authentication would be done by SSO, and since the web service directory could be a subdirectory of the main SSO page, then I could decrypt the cookie and get the username that way, but, that would be annoying for the mobile users, which would include the senior management.
So, what is a way to secure a REST service so that it is known whom is making the request so that authorization decisions can be made, and will work for iphones, android and blackberry smartphones.
I have the same problem so let me give you the details and would also appreciate feedback. Since you are using an internal system you have one extra option that I have listed.
My first option isn't perfect, yes it could be hacked but still - better than nothing. With each request you pass the device's unique identifier along with a hash. You generate the hash using a salt embedded in the application along with the id. On the server you match the incoming hash with one you generate at the server, with the passed unique identifier. If someone "roots" their device, and is smart enough they could find the salt - you can obscure it further but ultimately it could be stolen. Also, I keep all requests on SSL to just help hide the process. My "enhancement" to this process is to pass back new salts after each request. New devices get 1 chance to obtain the next salt or get locked out ... not sure about that step yet.
Now another approach, is to have the user enter a "salt" or username and password only an internal user would know - the device obtains a token and then passes it (on SSL) with each request. Nobody outside your company could obtain that so this is probably best. I can't use this since my app is in the app store.
Hope that helps! Let us all know if you ever found a good solution.
My current solution, in order to protect data in the system, is to force people to first log in to the application that the REST services support (our learning management system), as I have written an SSO solution that will write out a cookie with encrypted data.
Then, the REST service will look for that cookie, which disappears when you close the browser, and I don't care if the cookie is expired, I just need the username from it, then I can look in a config file to see if that user is allowed to use that REST service.
This isn't ideal, and what I want to do is redirect through the SSO code, and have it then send the person back to the REST service, but that is not as simple as I hoped.
My SSO code has lots of redirects, and will redirect someone to a spot they pick in the learning management system, I just need to get it to work with the other application.
Disclaimer: I'm not a Notes admin, I just wrote the application :), and I try to help our client to use it.
We provide a simple database with one agent to accept and process HTTP POST messages from Internet.
The Domino server where this database is going to be installed is configured for Single SignOn authentication for web access.
Is there a way so set only our database to use different type of authentication - i.e. Basic Authentication, so we can hit it like this to POST messages to the agent:
http://username:password#my.domino.server/mydb.nsf/myagent
I thought about another approach as well - to remove any form of auth, and pass the credentials in the POSTed data itself. Then the agent will take care to process or not the data, base on if the creds are OK. But this most probably will require some form of "impersonation" - I.e. to map somehow the anonymous user to the one, which has the rights to execute the agent. So, I valid answer to this question may be an advise how to set this up.
Additionally - we are looking at the web service approach (available in Domino 7.0+), but it will require changes on both sides - the sender (our publisher service) and the receiving agent. And most probably will lead back to the original question about how to authenticate the sender.
Any advice in that regard (even changing the approach) will be highly appreciated.
Cheers
Since Domino 7.0.2 there is a new kind of website rule entitled "Override Session Authentication" that allows you to specify, for a specific URL pattern (ex : /folder/myapp.nsf/myagent?*) to use BASIC auth even if the whole server is configured for session-based auth.
This was initially introduced for RSS readers (that cannot handle sessions).
More information here :
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.help.domino.admin.doc/DOC/H_OVERRIDING_SESSION_AUTHENTICATION_8847_STEPS.html
Although it's horribly insecure to allow this, it is possible using web site documents on the server.
Create a website document that has basic authentication for your database (it will need it's own domain name) and then everyone else can access the server through the default website document which uses session authentication.
I'd suggest adding Anonymous to the ACL of the database, with No access and nothing but Read public documents checked. Then, you can grant access to the agent by checking Allow Public Access users to view and run this agent in the Agent properties.
I don't know if it is possible to get the Authorization header into the agent to check the authentication. If there are only two parties communicating I would compute a hash of the message, a timestamp and a shared secret and use that to check access.
Edit
You won't be able to parse the Authorization header manually. Domino (at least 7.0.3) tries to do a session authentication if your request contains an authorization header, regardless of access settings on the object you request.
Here, put that URL in your Favorites toolbar :
http://www-01.ibm.com/support/knowledgecenter/SSKTMJ_8.5.3/welcome_Domino_8_5_3.html
Also did you know that your Notes client and Domino Server come with help databases full of very adequate documents ? Try the [Help] menu for starters.
Then, said help databases are usually in the aptlty named "help" folder". Open them.
Okay, I've asked on the Community Server Forums and was totally ignored. So I'll ask here. The OpenID provider (presumably janrain) for CommunityServer does not work with an SSL OpenID endpoint. I really don't know of a non SSL OpenID endpoint and even if I did...I'm not sure if I'd want to use it.
I have a community server installation and all of my users are complaining that the signup/login form appears to support openid but doesn't in reality. has anyone encountered this issue and addressed it?
Thanks in advance.
CS currently uses an old version of Janrain's C# library. I think the next version is expected to use dotnetopenid. But even in its current release I would expect it to work just fine with SSL OP endpoints. If it didn't, then no OpenIDs from myopenid.com would work for logging into CS and I would expect the CS guys would have noticed that.
However, if specific endpoints are broken, it may be a sign of another problem. If you can give specific OpenID endpoints that are not working then please send an email to dotnetopenid#googlegroups.com and I'll be happy to investigate it further.
There's a test OP Endpoint that is non-SSL that you can try out to see if it works by logging into your CS with this: http://nerdbank.org/opaffirmative/affirmativeidentity.aspx (yes, that's actually a valid OpenID you can log in with without using a password).