Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v10: KerberosScreen failing on internal Network #590

Closed
CriGoT opened this issue Sep 1, 2016 · 0 comments · Fixed by #594
Closed

v10: KerberosScreen failing on internal Network #590

CriGoT opened this issue Sep 1, 2016 · 0 comments · Fixed by #594
Assignees
Labels
bug This points to a verified bug in the code
Milestone

Comments

@CriGoT
Copy link
Contributor

CriGoT commented Sep 1, 2016

When using AD/LDAP connections with Kerberos Lock correctly identifies that the user is connecting from the internal network and displays the KerberosScreen.

screen shot 2016-09-01 at 18 30 39

However, when the user clicks the button nothing happens.The error registered in the browser is that the connection object does not have a get member.

screen shot 2016-09-01 at 18 36 12

screen shot 2016-09-01 at 18 36 31

Looking at the code the main issue is that the corpNetworkConnection is getting only the name of the connection from ssodata (notice the TODO).

In this scenario ssodata looks like this:

{
  "sso": "false",
   "connection" : "ad"
   "strategy" : "ad"
}

A simple fix would be to change this line to

  return  m.getIn(["sso", "connection"]) && Immutable.Map({name:m.getIn(["sso", "connection"]),strategy:m.getIn(["sso","strategy"])});
@hzalaz hzalaz added bug This points to a verified bug in the code v10 labels Sep 2, 2016
CriGoT added a commit to CriGoT/lock that referenced this issue Sep 5, 2016
Improves handling of the format sent by the server using and AD connection with Kerberos authentication.

When connecting from a corporate network a user can choose to connect using Kerberos or certificate authentication. In any of these cases lock relies in information provided by the server to validate that the user is in a corporate network and to obtain the name and strategy of the connection associated with the network. 

However, the format of the information is flat inside the `sso` object and not in the connection format used in other cases. The fix manages the flat format and creates a temporary object with the known format to allow `KerberosScreen` to work as expected.
cristiandouce pushed a commit that referenced this issue Sep 13, 2016
Improves handling of the format sent by the server using and AD connection with Kerberos authentication.

When connecting from a corporate network a user can choose to connect using Kerberos or certificate authentication. In any of these cases lock relies in information provided by the server to validate that the user is in a corporate network and to obtain the name and strategy of the connection associated with the network. 

However, the format of the information is flat inside the `sso` object and not in the connection format used in other cases. The fix manages the flat format and creates a temporary object with the known format to allow `KerberosScreen` to work as expected.
@hzalaz hzalaz modified the milestone: v10.3.0 Sep 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This points to a verified bug in the code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants