1. z.archive.aaa-dev@lists.opendaylight.org
  2. Messages
   Date   
Re: [OpenDaylight Discuss] On multi-tenancy support

Luis Gomez
 

Hi Dave,

Thanks for this detailed information. I will ask more in case of questions.

BR/Luis


On Aug 4, 2014, at 8:40 AM, Lenrow, Dave <david.lenrow@...> wrote:

Hi Luis,
I have worked with some other members of the community to map a proposal that would define the relationships in ODL among AAA, tenants, virtual networks, and group based policy. It has generally been well received when socialized, but we’ve not yet figured out how to translate this concept into cooperation and code within all the projects that would need to participate.
 
Clearly not happening for Helium and possibly a great thing to work on when broad community membership is face-to-face at September developer event.
 
In todays GBP requirements call we will discuss plans to align GBP and AAA with this proposed approach.
 
Below are links to some documents from the discussion to date. They may help you understand the direction we’re proposing, however they may require some narration by the authors. We’ve presented some of this on TWS previously and could do an update to TWS if that is of interest.
 

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 
 
It’s not yet  clear to me  how we staff the developers to implement long term architectural vision across projects in ODL. Folks with interest/availability to participate should raise their hands as we begin to think about long term improvements outside of the helium timeline.
 
 
 
Below is pasted an email from the discuss list discussing this as well
 
Since the first ODL Hackfest, we’ve been trying to figure out how to get on the same page about terminology and how we can use it to talk about what we’re building.
This spring, Colin Dixon, Liem Nguyen, and I took an action to propose a way to map AAA tools to some well defined entities and in the process to resolve ongoing confusion around what we mean by tenants, users, and virtual networks, in particular.
We presented this and got some good feedback from the TWS call on June 2.
 
What we proposed was a model with an entity called a domain (chosen by poll) that works as follows:
 
The “root” domain is created when the GBP system starts and it inherits access to  all of the physical and virtual network resources discovered by the startup process.
The root domain can include various users and roles with AAA support. Within the root domain an admin can be created and can then subsequently define which resources and actions the various root domain users are allowed to access.
The root domain can create one or more children, and for each can specify what resources and actions are available in the childrens “view” of the overall resource and policy world.
The parent child relationship can be extended recursively to an arbitrary depth.
Each child  domain also has a set of users and roles supported by AAA that are local to that domain. These define what various users are allowed to do withing the resource/policy view they inherit.
 
 
Email included below describes the vision of how this would work in general.
The OpenStack project, which will often sit atop ODL (and GBP) does not support arbitrarily deep recursion of “tenant like” entities. It is basically a one-deep hierarchy. Enclosed slides show how multiple instances of OpenStack provider/tenants could map onto a single instance of the recursive ODL network infrastructure model.
 
Within Group Based Policy it would be fantastic if we could figure out how to make GBP the policy language for describing the concentric circles of  ever-more restrictive “parental controls” as one marches down the ODL domain stack.  
 
Suggest we discuss this in a GBP arch meeting at a minimum. May touch enough areas that we want to discuss on TWS again?
 
I’ve uploaded some slides that help explain the thinking on the GBP Wiki

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 
 
Bring it on!
-drl
 
 
 
From: Lenrow, Dave 
Sent: Friday, May 23, 2014 9:20 AM
To: discuss@...; controller-dev@...
Subject: Expanding on N-deep tenant hierarchy
 
Some folks have asked me to restate my vision for how/why we need a flexible tenant concept. Please note that
 
One could imagine a strict hierarchy of control as follows in which each subsequent tenant entity has authority/scope/role defined and limited by it’s parent/child relationship through which it inherits a constrained view of the total resource pool.
 
 
Facitlities Based Provider – Owns switches, servers, fibre, etc.
    Virtual Cloud Provider – Sells access to a subset of the resources offered by FBP parent
        Corporate Customer – provides corporate wide access to subset of  resources offered by VCP parent
            Business unit of Corporation – provides on-demand self-service access to subset of resources offered by CC parent
                Admin in business Unit – provides on-demand, self-service access to subset of BU resources
                    BU developer – consumes on-demand, self-service subset of BU resources
                        BU production application – consumes resources as defined by developer with elastics scaleout-based on load.
                            Application module – can do stuff within envelope of BUA parent.
                                Etc.
 
In this case N=8, but the instant we decide that is the right constant, somebody will come up with a good reason for 9. If we decide N=25 to have lot’s of headroom we will feel dumb some day.
I claim we need an architecture that allows for a hierarchy that is arbitrarily deep.
 
 
FBP can decide that VCP 1 gets 80 of the bandwidth in the physical fabric and VCP 2 gets 20%, but with special express links between metro hubs.
VCP one can sell  LargeCo access to some dedicated resources and an ability to burst on-demand up to a limit X in a shared pool.
LargeCo can define which virtual networks are accessible to the Finance BU
FinBU can allow admin to choose developers who are allowed to request Gold QoS on their diffserv vnet
BU dev can contain the number of instances of paystubprinter allowed on-demand.
PayStubPrinter FinBU app can decide how/when to load balance across multi-link border interface
App module can stream log data within storage contstraints from FinBU (great-grand-parent)
Etc.
 
Above is kind of goofy contrived example, so please send nit picking to /dev/null.
 
Point is Tenancy cannot be flat, or shallow, but must be supported for potential complex hierarchy of control.
 
Within the hierarchy, the limits of what a child can do are always defined buy inheritance from their parent.
 
 
Authentication at any level of the hierarchy could be to a common, multi-tenant aware auth server or to an instance of auth-server with constrained/local context (e.g. FinBU auth server for FinBU and children).
 
Do others feel that this vision is sensible and needs to get reflected in our requirements?
 
It won’t surprise anyone that I think we need to build the enforcement of the rules of such a hierarchy into a controller based declarative intent NBI. I would suggest that the single writer of policy be the only trusted client of a completely trusted NBI and that the entire hierarchy of control and enforcement be built above that trusted interface.  As others have recommended, the controller would have no native sense of tenancy in the management/control plane (there are clearly requirements, e.g. overlapping tenant IP address spaces that need to be handled in tenant context in the data plane). The intent NBI would become the single-sign-on interface for AAA for non-infrastructure entities (e.g. securing controller-native bunldles and interfaces needs it’s own secure plumbing solution).
 
If folks want to talk me out of a single policy writer completely trusted, I won’t be surprised (and I’m sure the reasons will be compelling), but  the top of the plumbing AAA/policy stack needs to connect to the bottom of the intent based NBI stack cleanly with no AAA ambiguity.
 
I’m donning my flame retardant suit as I hit send and await our communities diverse views on my wacky vision of the future. Be gentle friends.
 
 
 
-drl
 
Dave Lenrow
Distinguished Architect
Advanced Technology Group - HP Networking
Hewlett-Packard, Littleton MA
+1 (617)-329-1861 (mobile)
@dlenrow
 
 
 
 
 
From: Rob Adams [mailto:readams@...] 
Sent: Monday, August 04, 2014 1:06 AM
To: Colin Dixon
Cc: Luis Gomez; <discuss@...>; Lenrow, Dave; groupbasedpolicy-dev@...; aaa-dev@...
Subject: Re: [OpenDaylight Discuss] On multi-tenancy support
 
Tenants are in the group-based policy model but group-based policy does not implement any sort of access control at the moment; we've been assuming that AAA would be provided by the restconf layer and we could plug into that.  So we should be ready to tie into whatever mechanism exists.

 

On Sun, Aug 3, 2014 at 8:05 PM, Colin Dixon <colin@...> wrote:

I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.
 
--Colin

 

On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:
Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
 


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
AAA Status meeting moved this week only 1 hour later

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Unless someone has a WebEx key, we will be meeting on Hangout:
 
 
Thanks,
Liem
 

Calendar

maven build fail for feature-aaa

George Zhao <George.Y.Zhao@...>
 

Hi

I don’t know if someone already filed a bug for this or not, when I tried to do a maven build from head, I got the following error.

 

It looks like something related to karaf.

 

 

[INFO] Reactor Summary:

[INFO]

[INFO] commons.aaa ....................................... SUCCESS [6.320s]

[INFO] aaa.project ....................................... SUCCESS [0.236s]

[INFO] aaa-authn-api ..................................... SUCCESS [6.825s]

[INFO] aaa-authn ......................................... SUCCESS [4.338s]

[INFO] aaa-authn-sts ..................................... SUCCESS [11.565s]

[INFO] aaa-authn-store ................................... SUCCESS [7.415s]

[INFO] aaa-authn-sssd .................................... SUCCESS [0.793s]

[INFO] aaa-authn-keystone ................................ SUCCESS [1.109s]

[INFO] aaa-idmlight ...................................... SUCCESS [0.946s]

[INFO] aaa-authz ......................................... SUCCESS [0.101s]

[INFO] aaa-authz-model ................................... SUCCESS [14.978s]

[INFO] features-aaa ...................................... FAILURE [2.203s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1:02.122s

[INFO] Finished at: Sat Aug 09 22:37:47 PDT 2014

[INFO] Final Memory: 52M/124M

[INFO] ------------------------------------------------------------------------

[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.1:features-create-kar (features-create-kar) on project features-aaa: Failed to create archive: Could not find artifact org.opendaylight.aaa:features-aaa:cfg:clients:0.1.0-SNAPSHOT in opendaylight-release (http://nexus.opendaylight.org/content/repositories/opendaylight.release/)

[ERROR]

[ERROR] Try downloading the file manually from the project website.

[ERROR]

[ERROR] Then, install it using the command:

[ERROR] mvn install:install-file -DgroupId=org.opendaylight.aaa -DartifactId=features-aaa -Dversion=0.1.0-SNAPSHOT -Dclassifier=clients -Dpackaging=cfg -Dfile=/path/to/file

[ERROR]

[ERROR] Alternatively, if you host your own repository you can deploy the file there:

[ERROR] mvn deploy:deploy-file -DgroupId=org.opendaylight.aaa -DartifactId=features-aaa -Dversion=0.1.0-SNAPSHOT -Dclassifier=clients -Dpackaging=cfg -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

[ERROR]

[ERROR]

[ERROR] org.opendaylight.aaa:features-aaa:cfg:0.1.0-SNAPSHOT

[ERROR]
Project dependency question

George Zhao <George.Y.Zhao@...>
 

Hello,

 

I saw on the spreadsheet,  AAA has dependencies on Yangtools and MD-SAL, however, I can only see yangtools dependency through maven pom.xml, I wonder if someone can explain to me where is the MD-SAL dependency coming from?

 

Thanks,

 

George
Re: Project dependency question

Wojciech Dec
 

Hi,

MD-SAL dependency is coming in from the AuthZ service piece, which hasn't been committed yet. Moreover the APIs generated by Yangtools depend on the MD-SAL broker components to get them to work.

Regards,
Wojciech.


On 10 August 2014 08:28, George Zhao <George.Y.Zhao@...> wrote:

Hello,

 

I saw on the spreadsheet,  AAA has dependencies on Yangtools and MD-SAL, however, I can only see yangtools dependency through maven pom.xml, I wonder if someone can explain to me where is the MD-SAL dependency coming from?

 

Thanks,

 

George


_______________________________________________
Aaa-dev mailing list
Aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev
Re: [OpenDaylight Discuss] On multi-tenancy support

Wojciech Dec
 

Hi Luis,

the currently proposed AuthZ service data-model + API factor in a multi-tenancy aspect by allowing authorization policies for resources to be nested covering multiple domains.
You can find this described in https://lists.opendaylight.org/pipermail/aaa-dev/2014-July/000036.html

Welcome all feedback on the matter.

Regards,
Wojciech.


On 4 August 2014 18:51, Luis Gomez <ecelgp@...> wrote:
Hi Dave,

Thanks for this detailed information. I will ask more in case of questions.

BR/Luis

On Aug 4, 2014, at 8:40 AM, Lenrow, Dave <david.lenrow@...> wrote:

Hi Luis,
I have worked with some other members of the community to map a proposal that would define the relationships in ODL among AAA, tenants, virtual networks, and group based policy. It has generally been well received when socialized, but we’ve not yet figured out how to translate this concept into cooperation and code within all the projects that would need to participate.
 
Clearly not happening for Helium and possibly a great thing to work on when broad community membership is face-to-face at September developer event.
 
In todays GBP requirements call we will discuss plans to align GBP and AAA with this proposed approach.
 
Below are links to some documents from the discussion to date. They may help you understand the direction we’re proposing, however they may require some narration by the authors. We’ve presented some of this on TWS previously and could do an update to TWS if that is of interest.
 

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 
 
It’s not yet  clear to me  how we staff the developers to implement long term architectural vision across projects in ODL. Folks with interest/availability to participate should raise their hands as we begin to think about long term improvements outside of the helium timeline.
 
 
 
Below is pasted an email from the discuss list discussing this as well
 
Since the first ODL Hackfest, we’ve been trying to figure out how to get on the same page about terminology and how we can use it to talk about what we’re building.
This spring, Colin Dixon, Liem Nguyen, and I took an action to propose a way to map AAA tools to some well defined entities and in the process to resolve ongoing confusion around what we mean by tenants, users, and virtual networks, in particular.
We presented this and got some good feedback from the TWS call on June 2.
 
What we proposed was a model with an entity called a domain (chosen by poll) that works as follows:
 
The “root” domain is created when the GBP system starts and it inherits access to  all of the physical and virtual network resources discovered by the startup process.
The root domain can include various users and roles with AAA support. Within the root domain an admin can be created and can then subsequently define which resources and actions the various root domain users are allowed to access.
The root domain can create one or more children, and for each can specify what resources and actions are available in the childrens “view” of the overall resource and policy world.
The parent child relationship can be extended recursively to an arbitrary depth.
Each child  domain also has a set of users and roles supported by AAA that are local to that domain. These define what various users are allowed to do withing the resource/policy view they inherit.
 
 
Email included below describes the vision of how this would work in general.
The OpenStack project, which will often sit atop ODL (and GBP) does not support arbitrarily deep recursion of “tenant like” entities. It is basically a one-deep hierarchy. Enclosed slides show how multiple instances of OpenStack provider/tenants could map onto a single instance of the recursive ODL network infrastructure model.
 
Within Group Based Policy it would be fantastic if we could figure out how to make GBP the policy language for describing the concentric circles of  ever-more restrictive “parental controls” as one marches down the ODL domain stack.  
 
Suggest we discuss this in a GBP arch meeting at a minimum. May touch enough areas that we want to discuss on TWS again?
 
I’ve uploaded some slides that help explain the thinking on the GBP Wiki

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 
 
Bring it on!
-drl
 
 
 
From: Lenrow, Dave 
Sent: Friday, May 23, 2014 9:20 AM
To: discuss@...; controller-dev@...
Subject: Expanding on N-deep tenant hierarchy
 
Some folks have asked me to restate my vision for how/why we need a flexible tenant concept. Please note that
 
One could imagine a strict hierarchy of control as follows in which each subsequent tenant entity has authority/scope/role defined and limited by it’s parent/child relationship through which it inherits a constrained view of the total resource pool.
 
 
Facitlities Based Provider – Owns switches, servers, fibre, etc.
    Virtual Cloud Provider – Sells access to a subset of the resources offered by FBP parent
        Corporate Customer – provides corporate wide access to subset of  resources offered by VCP parent
            Business unit of Corporation – provides on-demand self-service access to subset of resources offered by CC parent
                Admin in business Unit – provides on-demand, self-service access to subset of BU resources
                    BU developer – consumes on-demand, self-service subset of BU resources
                        BU production application – consumes resources as defined by developer with elastics scaleout-based on load.
                            Application module – can do stuff within envelope of BUA parent.
                                Etc.
 
In this case N=8, but the instant we decide that is the right constant, somebody will come up with a good reason for 9. If we decide N=25 to have lot’s of headroom we will feel dumb some day.
I claim we need an architecture that allows for a hierarchy that is arbitrarily deep.
 
 
FBP can decide that VCP 1 gets 80 of the bandwidth in the physical fabric and VCP 2 gets 20%, but with special express links between metro hubs.
VCP one can sell  LargeCo access to some dedicated resources and an ability to burst on-demand up to a limit X in a shared pool.
LargeCo can define which virtual networks are accessible to the Finance BU
FinBU can allow admin to choose developers who are allowed to request Gold QoS on their diffserv vnet
BU dev can contain the number of instances of paystubprinter allowed on-demand.
PayStubPrinter FinBU app can decide how/when to load balance across multi-link border interface
App module can stream log data within storage contstraints from FinBU (great-grand-parent)
Etc.
 
Above is kind of goofy contrived example, so please send nit picking to /dev/null.
 
Point is Tenancy cannot be flat, or shallow, but must be supported for potential complex hierarchy of control.
 
Within the hierarchy, the limits of what a child can do are always defined buy inheritance from their parent.
 
 
Authentication at any level of the hierarchy could be to a common, multi-tenant aware auth server or to an instance of auth-server with constrained/local context (e.g. FinBU auth server for FinBU and children).
 
Do others feel that this vision is sensible and needs to get reflected in our requirements?
 
It won’t surprise anyone that I think we need to build the enforcement of the rules of such a hierarchy into a controller based declarative intent NBI. I would suggest that the single writer of policy be the only trusted client of a completely trusted NBI and that the entire hierarchy of control and enforcement be built above that trusted interface.  As others have recommended, the controller would have no native sense of tenancy in the management/control plane (there are clearly requirements, e.g. overlapping tenant IP address spaces that need to be handled in tenant context in the data plane). The intent NBI would become the single-sign-on interface for AAA for non-infrastructure entities (e.g. securing controller-native bunldles and interfaces needs it’s own secure plumbing solution).
 
If folks want to talk me out of a single policy writer completely trusted, I won’t be surprised (and I’m sure the reasons will be compelling), but  the top of the plumbing AAA/policy stack needs to connect to the bottom of the intent based NBI stack cleanly with no AAA ambiguity.
 
I’m donning my flame retardant suit as I hit send and await our communities diverse views on my wacky vision of the future. Be gentle friends.
 
 
 
-drl
 
Dave Lenrow
Distinguished Architect
Advanced Technology Group - HP Networking
Hewlett-Packard, Littleton MA
@dlenrow
 
 
 
 
 
From: Rob Adams [mailto:readams@...] 
Sent: Monday, August 04, 2014 1:06 AM
To: Colin Dixon
Cc: Luis Gomez; <discuss@...>; Lenrow, Dave; groupbasedpolicy-dev@...; aaa-dev@...
Subject: Re: [OpenDaylight Discuss] On multi-tenancy support
 
Tenants are in the group-based policy model but group-based policy does not implement any sort of access control at the moment; we've been assuming that AAA would be provided by the restconf layer and we could plug into that.  So we should be ready to tie into whatever mechanism exists.

 

On Sun, Aug 3, 2014 at 8:05 PM, Colin Dixon <colin@...> wrote:

I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.
 
--Colin

 

On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:
Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
 


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss



_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
Re: Project dependency question

George Zhao <George.Y.Zhao@...>
 

Thanks for the explanation.

 

 

BR,

George

 

From: Wojciech Dec [mailto:wdec.ietf@...]
Sent: Monday, August 18, 2014 9:10 AM
To: George Zhao
Cc: aaa-dev@...
Subject: Re: [Aaa-dev] Project dependency question

 

Hi,

MD-SAL dependency is coming in from the AuthZ service piece, which hasn't been committed yet. Moreover the APIs generated by Yangtools depend on the MD-SAL broker components to get them to work.

Regards,

Wojciech.

 

On 10 August 2014 08:28, George Zhao <George.Y.Zhao@...> wrote:

Hello,

 

I saw on the spreadsheet,  AAA has dependencies on Yangtools and MD-SAL, however, I can only see yangtools dependency through maven pom.xml, I wonder if someone can explain to me where is the MD-SAL dependency coming from?

 

Thanks,

 

George


_______________________________________________
Aaa-dev mailing list
Aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev

 
Re: maven build fail for feature-aaa

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi Zhao,

 

This has been fixed a week or so ago…  Please pull the latest and let me know if it is still broken for you.

 

Hmm.. wonder why Jenkins did not catch it…  Will investigate….

 

Liem

 

From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of George Zhao
Sent: Saturday, August 09, 2014 10:43 PM
To: aaa-dev@...
Subject: [Aaa-dev] maven build fail for feature-aaa

 

Hi

I don’t know if someone already filed a bug for this or not, when I tried to do a maven build from head, I got the following error.

 

It looks like something related to karaf.

 

 

[INFO] Reactor Summary:

[INFO]

[INFO] commons.aaa ....................................... SUCCESS [6.320s]

[INFO] aaa.project ....................................... SUCCESS [0.236s]

[INFO] aaa-authn-api ..................................... SUCCESS [6.825s]

[INFO] aaa-authn ......................................... SUCCESS [4.338s]

[INFO] aaa-authn-sts ..................................... SUCCESS [11.565s]

[INFO] aaa-authn-store ................................... SUCCESS [7.415s]

[INFO] aaa-authn-sssd .................................... SUCCESS [0.793s]

[INFO] aaa-authn-keystone ................................ SUCCESS [1.109s]

[INFO] aaa-idmlight ...................................... SUCCESS [0.946s]

[INFO] aaa-authz ......................................... SUCCESS [0.101s]

[INFO] aaa-authz-model ................................... SUCCESS [14.978s]

[INFO] features-aaa ...................................... FAILURE [2.203s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1:02.122s

[INFO] Finished at: Sat Aug 09 22:37:47 PDT 2014

[INFO] Final Memory: 52M/124M

[INFO] ------------------------------------------------------------------------

[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.1:features-create-kar (features-create-kar) on project features-aaa: Failed to create archive: Could not find artifact org.opendaylight.aaa:features-aaa:cfg:clients:0.1.0-SNAPSHOT in opendaylight-release (http://nexus.opendaylight.org/content/repositories/opendaylight.release/)

[ERROR]

[ERROR] Try downloading the file manually from the project website.

[ERROR]

[ERROR] Then, install it using the command:

[ERROR] mvn install:install-file -DgroupId=org.opendaylight.aaa -DartifactId=features-aaa -Dversion=0.1.0-SNAPSHOT -Dclassifier=clients -Dpackaging=cfg -Dfile=/path/to/file

[ERROR]

[ERROR] Alternatively, if you host your own repository you can deploy the file there:

[ERROR] mvn deploy:deploy-file -DgroupId=org.opendaylight.aaa -DartifactId=features-aaa -Dversion=0.1.0-SNAPSHOT -Dclassifier=clients -Dpackaging=cfg -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

[ERROR]

[ERROR]

[ERROR] org.opendaylight.aaa:features-aaa:cfg:0.1.0-SNAPSHOT

[ERROR]
AuthN and netconf-tcp, netconf-ssh

Ed Warnicke (eaw) <eaw@...>
 

Liem,
Robert is wanting to explore using AAA for netconf-tcp and netconf-ssh for Helium.
As we’ve discussed, the need here is for netconf-{tcp,ssh} to be able to present credentials
to authN, and find out if they are valid credentials. Hopefully this should be simple. Could you help
Robert figure out the scope of the work?

Ed
Re: AuthN and netconf-tcp, netconf-ssh

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi Robert,

AAA comes a built-in IdM server with a set of REST API to manage users/roles/domains. You can use this API to validate credentials from your service, basically passing in username/password/domain and getting back a set of roles for that user on the given domain. You can then do further authorization if needed in your service.

More details on the IdM APIs here (Sorry, we are working on getting more formal documentation than a spreadsheet):

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0

This work is not yet checked in, since we are still working on integrating it into Karaf (having issue with JAXB/JSON in Karaf)...

Regards,
Liem

-----Original Message-----
From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Tuesday, August 19, 2014 7:48 AM
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...; Nguyen, Liem Manh
Subject: AuthN and netconf-tcp, netconf-ssh

Liem,
Robert is wanting to explore using AAA for netconf-tcp and netconf-ssh for Helium.
As we've discussed, the need here is for netconf-{tcp,ssh} to be able to present credentials to authN, and find out if they are valid credentials. Hopefully this should be simple. Could you help Robert figure out the scope of the work?

Ed
Documentation meeting for AAA

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Calendar

Re: AuthN and netconf-tcp, netconf-ssh

Ed Warnicke (eaw) <eaw@...>
 

Liem,
We would need a direct Java binding… do you have DOCs on how to do that?

Ed

On Aug 19, 2014, at 1:51 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Hi Robert,

AAA comes a built-in IdM server with a set of REST API to manage users/roles/domains. You can use this API to validate credentials from your service, basically passing in username/password/domain and getting back a set of roles for that user on the given domain. You can then do further authorization if needed in your service.

More details on the IdM APIs here (Sorry, we are working on getting more formal documentation than a spreadsheet):

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0

This work is not yet checked in, since we are still working on integrating it into Karaf (having issue with JAXB/JSON in Karaf)...

Regards,
Liem

-----Original Message-----
From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Tuesday, August 19, 2014 7:48 AM
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...; Nguyen, Liem Manh
Subject: AuthN and netconf-tcp, netconf-ssh

Liem,
Robert is wanting to explore using AAA for netconf-tcp and netconf-ssh for Helium.
As we've discussed, the need here is for netconf-{tcp,ssh} to be able to present credentials to authN, and find out if they are valid credentials. Hopefully this should be simple. Could you help Robert figure out the scope of the work?

Ed
Re: AuthN and netconf-tcp, netconf-ssh

Nguyen, Liem Manh <liem_m_nguyen@...>
 

No, we don't have any formal doc on that yet (will be Javadoc as soon as we get the IdM server integrated); but, it will be part of the OSGi IdmService. I will provide more developer info as soon as this gets integrated (hopefully) this week.

Regards,
Liem

-----Original Message-----
From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Tuesday, August 19, 2014 12:24 PM
To: Nguyen, Liem Manh
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: Re: AuthN and netconf-tcp, netconf-ssh

Liem,
We would need a direct Java binding... do you have DOCs on how to do that?

Ed
On Aug 19, 2014, at 1:51 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Hi Robert,

AAA comes a built-in IdM server with a set of REST API to manage users/roles/domains. You can use this API to validate credentials from your service, basically passing in username/password/domain and getting back a set of roles for that user on the given domain. You can then do further authorization if needed in your service.

More details on the IdM APIs here (Sorry, we are working on getting more formal documentation than a spreadsheet):

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0

This work is not yet checked in, since we are still working on integrating it into Karaf (having issue with JAXB/JSON in Karaf)...

Regards,
Liem

-----Original Message-----
From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Tuesday, August 19, 2014 7:48 AM
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...; Nguyen, Liem Manh
Subject: AuthN and netconf-tcp, netconf-ssh

Liem,
Robert is wanting to explore using AAA for netconf-tcp and netconf-ssh for Helium.
As we've discussed, the need here is for netconf-{tcp,ssh} to be able to present credentials to authN, and find out if they are valid credentials. Hopefully this should be simple. Could you help Robert figure out the scope of the work?

Ed
Re: AuthN and netconf-tcp, netconf-ssh

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi Robert,

 

While we are working on integrating the IdM server (almost there!), this is the service you can obtain from OSGi to do the authentication:

 

https://github.com/opendaylight/aaa/blob/master/aaa-authn-api/src/main/java/org/opendaylight/aaa/api/CredentialAuth.java

 

Currently, the only credential AAA supports out-of-the-box for direct authentication is username/password:  PasswordCredentials.

 

Please let me know if you have any questions…

 

Regards,

Liem

 

-----Original Message-----
From: Nguyen, Liem Manh
Sent: Tuesday, August 19, 2014 12:50 PM
To: 'Ed Warnicke (eaw)'
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: RE: AuthN and netconf-tcp, netconf-ssh

 

No, we don't have any formal doc on that yet (will be Javadoc as soon as we get the IdM server integrated); but, it will be part of the OSGi IdmService.  I will provide more developer info as soon as this gets integrated (hopefully) this week.

 

Regards,

Liem

 

-----Original Message-----

From: Ed Warnicke (eaw) [mailto:eaw@...]

Sent: Tuesday, August 19, 2014 12:24 PM

To: Nguyen, Liem Manh

Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...

Subject: Re: AuthN and netconf-tcp, netconf-ssh

 

Liem,

                We would need a direct Java binding… do you have DOCs on how to do that?

 

Ed

On Aug 19, 2014, at 1:51 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

 

> Hi Robert,

>

> AAA comes a built-in IdM server with a set of REST API to manage users/roles/domains.  You can use this API to validate credentials from your service, basically passing in  username/password/domain and getting back a set of roles for that user on the given domain.  You can then do further authorization if needed in your service. 

>

> More details on the IdM APIs here (Sorry, we are working on getting more formal documentation than a spreadsheet):

>

> https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0

>

> This work is not yet checked in, since we are still working on integrating it into Karaf (having issue with JAXB/JSON in Karaf)...

>

> Regards,

> Liem

>

> -----Original Message-----

> From: Ed Warnicke (eaw) [mailto:eaw@...]

> Sent: Tuesday, August 19, 2014 7:48 AM

> To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...; Nguyen, Liem Manh

> Subject: AuthN and netconf-tcp, netconf-ssh

>

> Liem,

>             Robert is wanting to explore using AAA for netconf-tcp and netconf-ssh for Helium.

>             As we've discussed, the need here is for netconf-{tcp,ssh} to be able to present credentials to authN, and find out if they are valid credentials.  Hopefully this should be simple.  Could you help Robert figure out the scope of the work?

>

> Ed

 
Installing AAA in Karaf...

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi guys,

 

Here are the steps I go through to get AAA installed on Karaf (the install stuff should go into the installation guide later, but at least just the contents for now):

 

1.       Build the AAA code

2.       Grab the controller code (git clone https://git.opendaylight.org/gerrit/p/controller.git)

3.       Build it!

4.       cd opendaylight/distribution/opendaylight-karaf/target/assembly

5.       bin/karaf (you may need to chmod u+x it)

6.       Add AAA repo (within karaf shell):  repo-add mvn:org.opendaylight.aaa/features-aaa/0.1.0-SNAPSHOT/xml/features

7.       List ODL features:  feature:list | grep odl  (you should see aaa in there as well).  There are 4 aaa features:

a.       odl-aaa-authn (Authentication feature)

b.      odl-aaa-authn-sssd (Authentication with SSSD)

c.       odl-aaa-authz (Authorization feature)

d.      odl-aaa-all (AAA features—includes all the above)

8.       You can then install any listed feature.  Example:  feature:install odl-aaa-authn

9.       Sanity check to see if AAA is up:  issue a token request:  curl -si -d 'grant_type=password&username=admin&password=odl&scope=pepsi' http://localhost:8181/oauth2/token

10.   If that above returns an error, something is wrong:  check the log under opendaylight/distribution/opendaylight-karaf/target/assembly/data/log.  You can also issue log:display in the Karaf shell and grep for stuff as well.

 

If you make your changes to your code, after rebuilding, you can refresh the repo in the Karaf shell by:

 

1.       Feature:uninstall <your feature>

2.       Repo-refresh

3.       Feature:install <your feature>

 

There may be a better way to hot deploy your code, but I don’t know how to do it yet…  If you do, please speak up J.

 

Other useful things I find in Karaf shell:

 

1.       Web:list (show you all the web endpoints you have)

2.       Feature:install webconsole (this installs the web console at http://localhost:8181/system/console/ username:karaf/password:karaf)  This provides a great tool to see how things are wired, what services/bundles/features are available, configuration, etc… tons of stuff.

 

 

For checking in your code, this Wiki page is a good start:  https://wiki.opendaylight.org/view/GettingStarted:Pulling,_Hacking,_and_Pushing_All_the_Code_from_the_CLI

 

After the setup as shown by the above wiki page, check-in process should be as simple as:

 

1.       Git checkout –b <your topic branch name>

2.       Git commit –a –s –m “comments for your checkin”

3.       Git review

4.       Go to Gerrit and invite at least 1 reviewer to review your code

 

Cheers,

Liem

 

 
Re: Installing AAA in Karaf...

Nguyen, Liem Manh <liem_m_nguyen@...>
 

FYI…

 

>> There may be a better way to hot deploy your code, but I don’t know how to do it yet… 

 

Bundle:watch <bundle id>  will allow you to hot deploy your bundle when you build it.

 

Liem

 

From: Nguyen, Liem Manh
Sent: Thursday, August 21, 2014 11:14 AM
To: 'aaa-dev@...'
Cc: 'Sujatha Joseph'
Subject: Installing AAA in Karaf...

 

Hi guys,

 

Here are the steps I go through to get AAA installed on Karaf (the install stuff should go into the installation guide later, but at least just the contents for now):

 

1.       Build the AAA code

2.       Grab the controller code (git clone https://git.opendaylight.org/gerrit/p/controller.git)

3.       Build it!

4.       cd opendaylight/distribution/opendaylight-karaf/target/assembly

5.       bin/karaf (you may need to chmod u+x it)

6.       Add AAA repo (within karaf shell):  repo-add mvn:org.opendaylight.aaa/features-aaa/0.1.0-SNAPSHOT/xml/features

7.       List ODL features:  feature:list | grep odl  (you should see aaa in there as well).  There are 4 aaa features:

a.       odl-aaa-authn (Authentication feature)

b.      odl-aaa-authn-sssd (Authentication with SSSD)

c.       odl-aaa-authz (Authorization feature)

d.      odl-aaa-all (AAA features—includes all the above)

8.       You can then install any listed feature.  Example:  feature:install odl-aaa-authn

9.       Sanity check to see if AAA is up:  issue a token request:  curl -si -d 'grant_type=password&username=admin&password=odl&scope=pepsi' http://localhost:8181/oauth2/token

10.   If that above returns an error, something is wrong:  check the log under opendaylight/distribution/opendaylight-karaf/target/assembly/data/log.  You can also issue log:display in the Karaf shell and grep for stuff as well.

 

If you make your changes to your code, after rebuilding, you can refresh the repo in the Karaf shell by:

 

1.       Feature:uninstall <your feature>

2.       Repo-refresh

3.       Feature:install <your feature>

 

There may be a better way to hot deploy your code, but I don’t know how to do it yet…  If you do, please speak up J.

 

Other useful things I find in Karaf shell:

 

1.       Web:list (show you all the web endpoints you have)

2.       Feature:install webconsole (this installs the web console at http://localhost:8181/system/console/ username:karaf/password:karaf)  This provides a great tool to see how things are wired, what services/bundles/features are available, configuration, etc… tons of stuff.

 

 

For checking in your code, this Wiki page is a good start:  https://wiki.opendaylight.org/view/GettingStarted:Pulling,_Hacking,_and_Pushing_All_the_Code_from_the_CLI

 

After the setup as shown by the above wiki page, check-in process should be as simple as:

 

1.       Git checkout –b <your topic branch name>

2.       Git commit –a –s –m “comments for your checkin”

3.       Git review

4.       Go to Gerrit and invite at least 1 reviewer to review your code

 

Cheers,

Liem

 

 
Question on Karaf pax-exam

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi Mathieu,

 

I found a linky on the Wiki for writing integration tests on Karaf:

 

https://wiki.opendaylight.org/view/CrossProject:Helium_Release_Vehicle_Brainstorming:Pure_Karaf#PAX-EXAM_Integration_Test

 

I would like to use this for AAA… Do you have a working project/example that I can take a look at?

 

Thanks,

Liem

 
Re: AuthN and netconf-tcp, netconf-ssh

Robert Varga -X (rovarga - Pantheon Technologies SRO@Cisco) <rovarga@...>
 

Hey Liem,

 

This looks like an API Maros (CC’d) will need to migrate the NETCONF bits away from AD-SAL.

 

Thanks,

Robert

 

 

From: Nguyen, Liem Manh [mailto:liem_m_nguyen@...]
Sent: Wednesday, August 20, 2014 8:06 PM
To: Ed Warnicke (eaw)
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: RE: AuthN and netconf-tcp, netconf-ssh

 

Hi Robert,

 

While we are working on integrating the IdM server (almost there!), this is the service you can obtain from OSGi to do the authentication:

 

https://github.com/opendaylight/aaa/blob/master/aaa-authn-api/src/main/java/org/opendaylight/aaa/api/CredentialAuth.java

 

Currently, the only credential AAA supports out-of-the-box for direct authentication is username/password:  PasswordCredentials.

 

Please let me know if you have any questions…

 

Regards,

Liem

 

-----Original Message-----
From: Nguyen, Liem Manh
Sent: Tuesday, August 19, 2014 12:50 PM
To: 'Ed Warnicke (eaw)'
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: RE: AuthN and netconf-tcp, netconf-ssh

 

No, we don't have any formal doc on that yet (will be Javadoc as soon as we get the IdM server integrated); but, it will be part of the OSGi IdmService.  I will provide more developer info as soon as this gets integrated (hopefully) this week.

 

Regards,

Liem

 

-----Original Message-----

From: Ed Warnicke (eaw) [mailto:eaw@...]

Sent: Tuesday, August 19, 2014 12:24 PM

To: Nguyen, Liem Manh

Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...

Subject: Re: AuthN and netconf-tcp, netconf-ssh

 

Liem,

                We would need a direct Java binding… do you have DOCs on how to do that?

 

Ed

On Aug 19, 2014, at 1:51 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

 

> Hi Robert,

>

> AAA comes a built-in IdM server with a set of REST API to manage users/roles/domains.  You can use this API to validate credentials from your service, basically passing in  username/password/domain and getting back a set of roles for that user on the given domain.  You can then do further authorization if needed in your service. 

>

> More details on the IdM APIs here (Sorry, we are working on getting more formal documentation than a spreadsheet):

>

> https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0

>

> This work is not yet checked in, since we are still working on integrating it into Karaf (having issue with JAXB/JSON in Karaf)...

>

> Regards,

> Liem

>

> -----Original Message-----

> From: Ed Warnicke (eaw) [mailto:eaw@...]

> Sent: Tuesday, August 19, 2014 7:48 AM

> To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...; Nguyen, Liem Manh

> Subject: AuthN and netconf-tcp, netconf-ssh

>

> Liem,

>             Robert is wanting to explore using AAA for netconf-tcp and netconf-ssh for Helium.

>             As we've discussed, the need here is for netconf-{tcp,ssh} to be able to present credentials to authN, and find out if they are valid credentials.  Hopefully this should be simple.  Could you help Robert figure out the scope of the work?

>

> Ed

 
Re: AuthN and netconf-tcp, netconf-ssh

Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi Robert,

 

I am not sure I quite understand your comment about API macro, but the AuthN piece in AAA is designed to be independent of either AD-SAL or MD-SAL.

 

Regards,

Liem

 

From: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) [mailto:rovarga@...]
Sent: Friday, August 22, 2014 1:04 PM
To: Nguyen, Liem Manh; Ed Warnicke (eaw); Maros Marsalek -X (mmarsale - Pantheon Technologies SRO at Cisco)
Cc: aaa-dev@...; Kristian Kocsis -X (kkocsis - Pantheon Technologies SRO at Cisco)
Subject: RE: AuthN and netconf-tcp, netconf-ssh

 

Hey Liem,

 

This looks like an API Maros (CC’d) will need to migrate the NETCONF bits away from AD-SAL.

 

Thanks,

Robert

 

 

From: Nguyen, Liem Manh [mailto:liem_m_nguyen@...]
Sent: Wednesday, August 20, 2014 8:06 PM
To: Ed Warnicke (eaw)
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: RE: AuthN and netconf-tcp, netconf-ssh

 

Hi Robert,

 

While we are working on integrating the IdM server (almost there!), this is the service you can obtain from OSGi to do the authentication:

 

https://github.com/opendaylight/aaa/blob/master/aaa-authn-api/src/main/java/org/opendaylight/aaa/api/CredentialAuth.java

 

Currently, the only credential AAA supports out-of-the-box for direct authentication is username/password:  PasswordCredentials.

 

Please let me know if you have any questions…

 

Regards,

Liem

 

-----Original Message-----
From: Nguyen, Liem Manh
Sent: Tuesday, August 19, 2014 12:50 PM
To: 'Ed Warnicke (eaw)'
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: RE: AuthN and netconf-tcp, netconf-ssh

 

No, we don't have any formal doc on that yet (will be Javadoc as soon as we get the IdM server integrated); but, it will be part of the OSGi IdmService.  I will provide more developer info as soon as this gets integrated (hopefully) this week.

 

Regards,

Liem

 

-----Original Message-----

From: Ed Warnicke (eaw) [mailto:eaw@...]

Sent: Tuesday, August 19, 2014 12:24 PM

To: Nguyen, Liem Manh

Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...

Subject: Re: AuthN and netconf-tcp, netconf-ssh

 

Liem,

                We would need a direct Java binding… do you have DOCs on how to do that?

 

Ed

On Aug 19, 2014, at 1:51 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

 

> Hi Robert,

>

> AAA comes a built-in IdM server with a set of REST API to manage users/roles/domains.  You can use this API to validate credentials from your service, basically passing in  username/password/domain and getting back a set of roles for that user on the given domain.  You can then do further authorization if needed in your service. 

>

> More details on the IdM APIs here (Sorry, we are working on getting more formal documentation than a spreadsheet):

>

> https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit#gid=0

>

> This work is not yet checked in, since we are still working on integrating it into Karaf (having issue with JAXB/JSON in Karaf)...

>

> Regards,

> Liem

>

> -----Original Message-----

> From: Ed Warnicke (eaw) [mailto:eaw@...]

> Sent: Tuesday, August 19, 2014 7:48 AM

> To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...; Nguyen, Liem Manh

> Subject: AuthN and netconf-tcp, netconf-ssh

>

> Liem,

>             Robert is wanting to explore using AAA for netconf-tcp and netconf-ssh for Helium.

>             As we've discussed, the need here is for netconf-{tcp,ssh} to be able to present credentials to authN, and find out if they are valid credentials.  Hopefully this should be simple.  Could you help Robert figure out the scope of the work?

>

> Ed

 
Re: AuthN and netconf-tcp, netconf-ssh

Ed Warnicke (eaw) <eaw@...>
 

Liem,
Think of it this way:
We have a bundle.  The bundle gets user credentials.  It needs to via a java service ask the AuthN to whether
those credentials are valid or not (and what roles they correspond to).

How would we do that?

Ed
On Aug 22, 2014, at 3:44 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:

Hi Robert,
 
I am not sure I quite understand your comment about API macro, but the AuthN piece in AAA is designed to be independent of either AD-SAL or MD-SAL.
 
Regards,
Liem
 
From: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) [mailto:rovarga@...] 
Sent: Friday, August 22, 2014 1:04 PM
To: Nguyen, Liem Manh; Ed Warnicke (eaw); Maros Marsalek -X (mmarsale - Pantheon Technologies SRO at Cisco)
Cc: aaa-dev@...; Kristian Kocsis -X (kkocsis - Pantheon Technologies SRO at Cisco)
Subject: RE: AuthN and netconf-tcp, netconf-ssh
 
Hey Liem,
 
This looks like an API Maros (CC’d) will need to migrate the NETCONF bits away from AD-SAL.
 
Thanks,
Robert
 
 
From: Nguyen, Liem Manh [mailto:liem_m_nguyen@...] 
Sent: Wednesday, August 20, 2014 8:06 PM
To: Ed Warnicke (eaw)
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: RE: AuthN and netconf-tcp, netconf-ssh
 
Hi Robert,
 
While we are working on integrating the IdM server (almost there!), this is the service you can obtain from OSGi to do the authentication:
 
 
Currently, the only credential AAA supports out-of-the-box for direct authentication is username/password:  PasswordCredentials.
 
Please let me know if you have any questions…
 
Regards,
Liem
 
-----Original Message-----
From: Nguyen, Liem Manh 
Sent: Tuesday, August 19, 2014 12:50 PM
To: 'Ed Warnicke (eaw)'
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: RE: AuthN and netconf-tcp, netconf-ssh
 
No, we don't have any formal doc on that yet (will be Javadoc as soon as we get the IdM server integrated); but, it will be part of the OSGi IdmService.  I will provide more developer info as soon as this gets integrated (hopefully) this week.
 
Regards,
Liem
 
-----Original Message-----
From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Tuesday, August 19, 2014 12:24 PM
To: Nguyen, Liem Manh
Cc: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...
Subject: Re: AuthN and netconf-tcp, netconf-ssh
 
Liem,
                We would need a direct Java binding… do you have DOCs on how to do that?
 
Ed
On Aug 19, 2014, at 1:51 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:
 
> Hi Robert,
>
> AAA comes a built-in IdM server with a set of REST API to manage users/roles/domains.  You can use this API to validate credentials from your service, basically passing in  username/password/domain and getting back a set of roles for that user on the given domain.  You can then do further authorization if needed in your service. 
>
> More details on the IdM APIs here (Sorry, we are working on getting more formal documentation than a spreadsheet):
>
>
> This work is not yet checked in, since we are still working on integrating it into Karaf (having issue with JAXB/JSON in Karaf)...
>
> Regards,
> Liem
>
> -----Original Message-----
> From: Ed Warnicke (eaw) [mailto:eaw@...]
> Sent: Tuesday, August 19, 2014 7:48 AM
> To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); aaa-dev@...; Nguyen, Liem Manh
> Subject: AuthN and netconf-tcp, netconf-ssh
>
> Liem,
>             Robert is wanting to explore using AAA for netconf-tcp and netconf-ssh for Helium.
>             As we've discussed, the need here is for netconf-{tcp,ssh} to be able to present credentials to authN, and find out if they are valid credentials.  Hopefully this should be simple.  Could you help Robert figure out the scope of the work?
>
> Ed
61 - 80 of 1823