Contradictory settings in FreeSWITCH SIP profile - acl

I am working with a simple FreeSWITCH installation, with the vanilla demo configuration. I see that the Internal SIP profile contains:
<param name="apply-inbound-acl" value="domains"/>
<param name="auth-calls" value="$${internal_auth_calls}"/>
The first line means that if a caller's IP is on the 'domains' list that they do NOT need to authenticate. The second line means that in order to use this SIP profile the user must be authenticated (internal_auth_calls is true).
Aren't these two lines contradictory? Why allow a user to not authenticate for this SIP profile, and then say they must authenticate to use this SIP profile?

Related

SIP trunking and call routing in Kamailio

I was using freepbx, but because of some limits I installed kamailio on another machine.
I want to have a route for outgoing calls to NGN(was peer friend siptrunk in freepbx), which handles call setups started from extensions registered on kamailio.
and another route which send incoming calls to a freepbx ivr.
how can I do that?
Kamailio controlled via config file. You can add if operator based on any info you want(source ip, destination number etc etc ) and choose for each own route.
You also can use already writed module like carrierroute https://kamailio.org/docs/modules/3.0.x/modules/carrierroute.html, which use prefix table for selection.

CAS X.509 auth with attributes from database

I want to configure Apereo CAS 6.0.x to perform X.509 authentication and then retrieve principal attributes from a database table.
Rudimentary X.509 authentication is working with these lines in application.properties (and appropriate reverse proxy setup):
cas.authn.x509.extractCert=true
cas.authn.x509.sslHeaderName=SSL_CLIENT_CERT
cas.authn.x509.principalDescriptor=SUBJECT_DN
The default "Log In Successful" page shows that it knows how to get my certificate's subject DN.
But I can't figure out how to tell CAS to then use that subject DN value to query my database for additional attributes.
This page explicitly mentions my need (though with LDAP instead of JDBC), but does not say specifically how to achieve it:
In many cases it is necessary to perform authentication by one means and resolve principals by another. The PrincipalResolver component provides this functionality. A common use case for this this mix-and-match strategy arises with X.509 authentication. It is common to store certificates in an LDAP directory and query the directory to resolve the principal ID and attributes from directory attributes. The X509CertificateAuthenticationHandler may be be combined with an LDAP-based principal resolver to accommodate this case.
What properties need to be set so that the X509 authentication handler resolves the principal against the database?
The missing ingredient was this line in application.properties:
cas.authn.x509.principalType=SUBJECT_DN
Without it, CAS does not attempt to query any attributeRepository settings that you may have.

Edit password_query in Dovecot for 2 factor auth

I want to add two-factor authentication to dovecot and thought of appending a OTP to the normal password a user has then sending that "new" password to Dovecot so i wondered whether it is possible to edit the password_query in dovecot-sql.conf.ext in such a way that it includes a section where the OTP part of the password is verified.
The authentication in dovecat can work via PAM. Most two factor authentication systems (to be specific OTP systems) add the second factor by just appending the OTP value after the password like:
mySecretPassword788293
This is sent to the authentication backend which knows, how to haƄdle this.
This means that the PAM stack would only request one password (which consists of the static part/knowledge and the OTPpart/possession) and have the OTP backend verify this.
E.g. you could use privacyIDEA to manage your 2nd factors in conjunction with PAM. http://privacyidea.readthedocs.io/en/latest/application_plugins/index.html
Disclaimer: I am core developer of privacyIDEA

Problems with WebSession when executing a WebService (GeneXus)

Here is the problem: I have a KB Called APP1 that will execute an WebService of an Identity Provider (centralizes all the logins/sessions for different applications) that will return true if there is a logged user in current WebSession that has been granted to access the Application or false otherwise. When I create an web panel at the same KB as the Identity Provider, it works just fine, I get TRUE when there's a logged user, and FALSE when there's not. But when I call it from APP1 it always returns false, I believe that the problem is because the WebSession won't work properly when called through an WS. Any ideas of how to solve it?
My first advice is to try using GAM Single Sign on (X Evolution 3)
WebServices should be Stateless. I think that using the Database instead of WebSession could do the job.
Nonetheless, in order to call a restful WebService you will have to do something more complex as dealing with CookieContainers as stated in the following link.
Consider this solution:
User tries to access App1
There's no web session (App1 doesn't know who is connecting)
App1 redirects User to an IdentityProvider's special login page
If User is not logged, it provides credentials and logs in
IdentityProvider has a session for the user (it knows who is connecting), then it redirects to the referer, appending to the url an encrypted userid parameter.
App1 decodes the parameter, now it knows who is connecting.
App1 saves the userid to the web session, now the user is authenticated
App1 and IdentityProvider must share an encryption key.
Consider that if the encryption key gets compromised or cracked anyone can impersonate another user.
Depending in how secure you want your system to be, you should study other security issues:
every time the user connects it's encrypted login is the same an it shows in the url, it can be easily solved adding a nonce or salt.
The system could be abused generating multiple requests until it gets a valid encrypted userid. It can be mitigated using a large Salt and/or blocking multiple attempts from the same source.
Note that this isn't a tested protocol and I didn't study the security in depth. I got some inspiration from OpenId, but this is a simplified protocol and I could be missing security holes.

Registering on No-quota push notifications

On my WP8 app, I followed instructions from here to register on push notifications service MPNS.:
HttpNotificationChannel pushChannel;
// The name of our push channel = the CN from certificate
string channelName = "CN-from-cert";
However, channel URI returned from the MPNS is always http:// and it seems like it's not using this secured connection. So, my question is:
How can I verify if my channel is using no-quote (secure) connection
What is needed on the client side (WP8 app)?
What is needed on the server side (sending push notifications)?
Many thanks.
I think you need to set ServiceName property (not channelName) to your service's domain name exactly as it appears on CN property in the server certificate that you will use. P.e., if your certificate's CN=www.mydomain.com, you must set Channel.ServiceName="www.mydomain.com". Channel name my be anyone that you like. This is at client side.
At server side you need to upload your cert file to developer.windowsphone.com dashboard and to your server too (with the private key).
You can check if MPNS recognize your secure channel by checking if channel URI generated starts with https:// instead http://. This not ensure that your server can send trusted notifications since it depends on if you have the same certificate in your server and specify it correctly in all petitions, but tells you that client side is ok.
You have detailed information about how to configure your server here:
http://msdn.microsoft.com/en-US/library/windowsphone/develop/ff941099%28v=vs.105%29.aspx
Best practices to implement a push notification system (including authenticated servers):
http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/10/22/recommended-practices-for-using-microsoft-push-notification-service-mpns.aspx