i'm working on setting up an 802.1x authentication though a 6224 Switch Dell To a FreeRADIUS who will check in an LDAP server for the user and retreive the TunnelPrivateGroupId and the others informations for the switch.
I already set up custom attributes and the attribute map on the FreeRADIUS to retreive my custom attributes from the LDAP.
In localhost, the authentication works fine and i can retreive my custom attributes.
But though my computer (who speak with EAP-PEAP), my FreeRadius validate the module ldap but never set the Auth-Type to LDAP.
My Computer --> Switch --> FreeRADIUS --> LDAP
screenshoot of an authentication attempt with my computer
Where the red arrow is where the Auth-Type is writen by the module when the authentication is ok, but it never happened.
As i say again, in localhost, the authentication works fine and the Auth-Type is writen by the module because it's not going though the EAP PEAP method.
I made every modifications on the default and inner-tunnel sites to get it worked in localhost and from my switch.
If you have any idea, i take it ^^
(i try to explain my problem as mush as i can. Sorry for any english errors, it's not my main language)
See that line WARNING: No "known good" password found in LDAP.... It's not just there for decoration :)
The problem is you haven't correctly mapped an LDAP attribute to the Password-With-Header attribute in FreeRADIUS.
Verify that there are mappings in your LDAP attrmap file for Password-With-Header and NT-Password and that the LDAP attributes (on the right side of the mapping) actually exist in the User object in LDAP.
Which EAP methods you can perform are determined by what password attributes you have. If you have a hashed version of the password in LDAP and no NT-Password attribute, you are limited to EAP-TTLS-PAP, and you should comment out any references to PEAP in your eap.conf file to prevent the server from negotiating it.
Related
I'm trying to figure out how ASP.NET internally validates that a cookie will allow the user to access the application.
CookieAuthenticationMiddleware will set .AspNet.Cookies with an encrypted value. After .NET successfully decrypts the cookie on a request, what validation occurs then?
Developing locally with IISExpress if I have an application (#1) that sets an authentication Cookie after the user logs in, and I create a complete new application (#2) also running on localhost, that is also using CookieAuthentication. When I access #2 it will read the cookie from #1 and allows the user to access the application as well.
I'm trying to understand what the limits are for cookie authentication.
There's not really any "validation" per se. The cookie's encrypted key is used to reference the user that should be "logged in". It works in a very similar way to sessions, where the session cookie holds an encrypted session id that the server can use to look up and restore the session via.
The encryption/decryption is based on the machine key, which either may be explicitly set in the Web.config or generated automatically by ASP.NET. Only applications that share the same machine key may decrypt the cookie, which is why it's so important to protect your machine key.
Anyways, there's two factors involved here. First, cookies are domain bound: only the domain or subdomains of the domain the cookie is set on will be given the cookie. This is handled by the client (i.e. browser). Your two applications currently are able to both see the cookie because they're both running on localhost. However, if you were to deploy one at foo.com and the other at bar.com, then they would no longer be able to see each other's cookies.
Second, the machine key is typically by server (unless you explicitly set it in the Web.config per app). As a result, sites running on the same machine can usually decrypt each other's cookies (assuming they see them in the first place, which again, is based on their domain).
It's not clear whether you're happy or not about this arrangement. If your goal is to segregate the two sites running locally, such that they don't share cookies, you have a couple of options.
You can explicitly set a different machine key for each site in their respective Web.config files. They'll still receive any cookies set by the other site, but they'll no longer be able to decrypt them, which basically results in them being ignored.
You can customize the auth cookie name. Instead of using the default cookie name you can make one .Site1.Auth and the other .Site2.Auth. Then, even though either site will also receive the cookie for the other site, it will simply ignore it, because it's not the auth cookie for it.
If, however, you're intending to rely on this behavior in production as well (i.e. you actually want logging into one site to log you into the other as well), then you'll need to explicitly set the machine key to the same value in both site's Web.config files. Additionally, you'll need to deploy them on the same domain, or at least subdomains of that domain. In the case of subdomains, you'll need to set the cookie domain to be the wildcard domain .mydomain.com for both. Then, you could have one at foo.mydomain.com and another at bar.mydomain.com, and they'd both see the cookie because it was set on .mydomain.com. If you leave it the default, set on the actual domain of the site, then bar.mydomain.com could not see a cookie set by foo.mydomain.com because that cookie would be explicitly set only for foo.mydomain.com.
The primary validations are encryption and expiration. If apps share an encryption context (e.g. machine key) then they can share auth cookies (providing other client side sharing rules like domains and paths are satisfied). So yes it's expected that two apps using IIS Express localhost on the same machine would share cookies by default.
The expiration is also embedded in the encrypted value so the client can't tamper with it.
For my JSF/TomEE application, I have a NoSQL database with users and roles that specifies how users can access resources (basically, IDs in a url parameter) either read-only or write.
I want to implement security and this post gave me some ideas but I am keen to try a 3rd party library - probably Shiro or PicketLink. The rule is that users will authenticate themselves with a client certificate, and if that is not provided, they will be authenticated as a default guest user.
Surprisingly, I am having a bit of trouble finding some information on how to do this in Shiro, it doesn't look straight forward. It is a bit of a surprise to me that there is nothing "out of the box" in Shiro to implement client certificate authentication.
So I think I have to create a Realm to "connect" Shiro with my database. Then I read I might need to extend org.apache.shiro.authc.UsernamePasswordToken to read the certificate and pass it to Shiro. Then I suppose I have to restrict access to content in JSF xhtml pages (using the rendered attribute for example) and I suppose that even in all methods of the Named Managed beans I will need to check the permissions.
Also, It is not clear to me how I can assign the guest user when a certificate is not provided, since apparently it is TomEE the one who validates the client, so if no certificate is provided, my code will not get executed to assign the guest user. I could open two different ports in TomEE, but then the access will not be unified, since I want to treat the guest user uniformely, as any other user in the system. How can this be done?
Is this implemented in a easier way in PicketLink? (which is also better prepared for JSF)
OK, it took me a while and a lot of research, so I will summarise my findings dramatically. I documented everything but do not want to create a book chapter.
So I decided to go with Shiro, and everything I describe works and can be done. This X509certificate project for Shiro was quite useful. Basically, you need to implement a Realm overriding two methods (one for authentication and another for authorisation) - there is a class to extend in the code I mentioned before.
The distiction of a user not providing a cert can be done in the Shiro Filter, so when no token (certificate) is provided, one can be created on the fly or read from a keystore.
For restricting access in JSF there are some shiro tags that can help, no need to use rendered. I have checked permissions also in the beans or other classes accessing the database. This works once the permissions have been established in the authorisation method.
The issue with Tomcat can be solved by using <Connector port="..." ClientAuth="want" ... which will ask for a certificate but will not stop the user if no certificate is provided.
Is there any way to disable the authentication requirement for accessing the API Documentation endpoints provided by the apiDiscovery-1.0 feature?
I have the apiDiscovery-1.0 feature enabled on Liberty 16.0.0.4.
I am able to see the swagger documents when I access /ibm/api/explorer as expected, but I am required to authenticate.
I am only able to authenticate by using credentials defined in a basicRegistry element within my server.xml. However, I want to eliminate this basicRegistry from my server configuration.
You can do that in the latest Beta (https://developer.ibm.com/wasdev/downloads/liberty-profile-beta/)
With that driver, you only need apiDiscovery-1.0 (SSL is optional).
The default address for the public endpoint is http://host:port/api/explorer
You can change the "/api" portion by using the publicURL attribute in the apiDiscovery element in server.xml, for example:
<apiDiscovery publicURL="/myPublicAPI" />
This is targeted for Liberty's next release, 17.0.0.1.
Please note that in the public endpoint, internal endpoints (such as JMX, Batch, etc) are not displayed - only your deployed applications.
For the internal endpoints, you can use /ibm/api/explorer (which remains requiring SSL and authentication).
I believe you can't remove the requirement for authentication for apiDiscovery for security reasons.
I doubt this helps but, you shouldn't "only be able to authenticate using credentials defined in a basicRegistry element within my server.xml" and instead any supported authentication mechanics should work like quickStartSecurity, LDAP, etc (and they can be set in any configuration file that is read by the server, not just server.xml). For example, you should be able to use quickStartSecurity in wlp/usr/shared/config to apply an Admininistrator role for all servers under that /wlp/usr/servers/ directory.
I have a webapplication using spring security. I'd like to login using an account i have configured on the WSO2 identity server using OpenID.
I can login just fine, the identity server asks for the password and redirects me back to my webapplication. So far, so good. However, when i try to request additional attributes using the attribute-exchange, i get empty values.
I have tried a few different types:
schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
axschema.org/namePerson/first
urn:scim:schemas:core:1.0:name.givenName
schema.openid.net/2007/05/claims/nickname
wso2.org/claims/givenname
But none of them seem to yield any results.
Am i missing something obvious?
The reason may be the fields are empty as well.
Can you try with the following claim URI, http://wso2.org/claims/role. By default all users have the everyone role. So that value should be returned.
I've seen several JMeter threads that kind of touch on my issue, but none seem to address my specific problem.
The problem is - the web-site that I am testing, works like this:
A home-page with logon fields, and a submit button. When you first
browse to this page in a browser, a PHPSESSID cookie is set (comes down in the Response Header) with a
unique Value, to identify the session.
When the user clicks on the login button (username and password on
this page are irrelevant in the system's current state), the web
server redirects to a different server running LDAP, via shibboleth.
Shibboleth needs the value of the PHPSESSID cookie, to proceed. (to validate that the user is coming from a correct, federated server).
The user then enters their account username and password, and clicks
the login button.
The (valid) account is logged in to the LDAP server; if the account
did not exist on the original (1) server, then shibboleth maps the
LDAP fields over to the account database on the original server.
Then the user is logged in to the original server (1) to the
newly-created account, and redirected to the original page.
There's some other SAML data that's exchanged - which I don't think is going to be a problem. . . so far, the problem seems to be this cookie.
Where JMeter is falling down, is in step 2.
If I do not set a cookie manager, the LDAP server says that I do not
have cookies enabled. (this error is in the response data).
If I set the HTTP cookie manager, with no PHPSESSID cookie specified,
the LDAP server says that I do not have cookies enabled. (it does not matter which Cookie Policy I set it to)
If I specify the PHPSESSID cookie value - of course, each user needs
to have an unique value, so this will be wrong. . . So I set a
RegExp post processor for the initial page, to extract the PHPSESSID
value from the Request Header, and place it into a variable
${PHPSession} Then I specify a value, in HTTP Cookie Manager, for the
PHPSESSID cookie, of ${PHPSession} . . . and LITERALLY, in the
header, the ** thing submits a "Cookie: PHPSESSID=${PHPSession}"
So then, I read THIS. . .
https://issues.apache.org/bugzilla/show_bug.cgi?id=28715
Which says, in effect, (paraphrased) "...cookie manager doesn't expand user variables..." then "... okay, we fixed it... it does expand user variables..." then "... well, no, not in THAT field, it's not designed to do THAT."
So... basically, they're saying, HTTP Cookie Manager can not manage session cookies that have an unique value for each user. (even though, this is what I thought it's whole purpose was).
How else can I set and submit a unique cookie for each user whose value is extracted from the first Response Header?
This is perhaps the most difficult task of programming a load test these days. I would say your problem could be related to failure to make the LDAP authentication right with the server, i.e. not passing in a new seesion ID each time. Look at using the LDAP Request sampler to pass in the token that way, both at Step 2 and for use later on in the script. You can go all out and build LDAP requests to really exercise your application. Hope this sheds some light on your problem!