Re: [DISCUSS] - Move to 2.0.0

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Brian Demers
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon <[hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Les Hazlewood-2
I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers <[hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon <[hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Brian Demers
This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:


I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers <[hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon <[hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

fpapon
I found this one:
https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming

It seems to be the same :)
regards,
François
[hidden email]
Le 05/04/2020 à 13:32, Brian Demers a écrit :
This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood [hidden email] wrote:


I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers [hidden email] wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon [hidden email] wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

    
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

otter606
In reply to this post by Brian Demers
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers <[hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Rob Young
Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams <[hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers <[hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Brian Demers
OAuth support has been on the top of my list for a while too! We added a bearer token filter in 1.5, but that is only part of the way there for just one flow.

Anything specific you are looking for? Resource Server? A standard redirect (auth code flow)? OIDC support? etc

-Brian

On Apr 5, 2020, at 7:59 AM, Rob Young <[hidden email]> wrote:


Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams <[hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers <[hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Rob Young
Cool!  This isn’t my specialty so I might get the terms wrong.  For me I think it’s the redirect authentication that I’m looking for.  Basically you implement a web application and want to let users log in via an oauth service like google.

On Sunday, April 5, 2020, Brian Demers <[hidden email]> wrote:
OAuth support has been on the top of my list for a while too! We added a bearer token filter in 1.5, but that is only part of the way there for just one flow.

Anything specific you are looking for? Resource Server? A standard redirect (auth code flow)? OIDC support? etc

-Brian

On Apr 5, 2020, at 7:59 AM, Rob Young <[hidden email]> wrote:


Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams <[hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers <[hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--


--

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

fpapon
In reply to this post by Brian Demers
Yes, +1 for OAuth support!
regards,
François
[hidden email]
Le 05/04/2020 à 15:11, Brian Demers a écrit :
OAuth support has been on the top of my list for a while too! We added a bearer token filter in 1.5, but that is only part of the way there for just one flow.

Anything specific you are looking for? Resource Server? A standard redirect (auth code flow)? OIDC support? etc

-Brian

On Apr 5, 2020, at 7:59 AM, Rob Young [hidden email] wrote:


Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams <[hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers <[hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--
Rob Young

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Benjamin Marwell
In reply to this post by fpapon
I want to throw in JSON web tokens (JWT).

It is a mess to work with them right now.

JWT can also be very complicated. They can only hold Authentication data, or they can hold roles, or even permission (if it is not getting too long).
I settled to create another realm. If the JWT contains EVERYTHING, the other realms must be skipped (that's the whole point). If it does only contain authc, there must be a possibility to search either the other realms or a special authz-only-realm. The latter is not possible atm because AuthorizingRealms extend AuthenticatingRealm.

It is not hard to create a JWT Authc realm, though. As the Token class is different, login will just skip the JWT realm.

… and there is so much more to it!


Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <[hidden email]>:
Yeah, it seems to be the same indeed.

Regards
JB

> Le 5 avr. 2020 à 13:38, Francois Papon <[hidden email]> a écrit :
>
> I found this one:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> It seems to be the same :)
>
> regards,
>
> François
> [hidden email]
>
> Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> This one?
>>
>> https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md
>>
>> -Brian
>>
>>> On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:
>>>
>>> 
>>> I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔
>>>
>>>> On Sat, Apr 4, 2020, 5:17 PM Brian Demers <[hidden email]> wrote:
>>>> +1
>>>>
>>>> Off the top of my head we have (I'm sure there is more, but ):
>>>>
>>>> * Package name / artifact structure cleanup (breaking change, but minor impact)
>>>> * Remove CAS modules
>>>> * Replace deprecated code (or move to an implementation/private package, for anything still needed)
>>>> * Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
>>>> * Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)
>>>>
>>>> The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
>>>> We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
>>>> That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Sat, Apr 4, 2020 at 8:29 AM Francois Papon <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to start a thread about the next major release: 2.0.0.
>>>>> I think we should move forward on it and only fix bug on the 1.x branches.
>>>>>
>>>>> There is always some issues related to the version in Jira:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>>>
>>>>> We can move also the issues list from the 1.6.0 to the 2.0.0:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12346916
>>>>>
>>>>> I noticed an existing branch about api changes on github:
>>>>>
>>>>> https://github.com/apache/shiro/tree/2.0-api-design-changes
>>>>>
>>>>> I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.
>>>>>
>>>>> Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.
>>>>>
>>>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>>>>
>>>>> We could start a formal vote to validate the plan.
>>>>>
>>>>> Feedback are welcome!
>>>>>
>>>>> regards,
>>>>> --
>>>>> François
>>>>> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

sreenivas harshith
Hi,

Provide native Integrations of pac4j with shiro, jwt , oauth, feature parity with other security frameworks like spring , spring security and others in the .net c# world.





On Mon, Apr 6, 2020 at 12:23 PM +0530, "Benjamin Marwell" <[hidden email]> wrote:

I want to throw in JSON web tokens (JWT).

It is a mess to work with them right now.

JWT can also be very complicated. They can only hold Authentication data, or they can hold roles, or even permission (if it is not getting too long).
I settled to create another realm. If the JWT contains EVERYTHING, the other realms must be skipped (that's the whole point). If it does only contain authc, there must be a possibility to search either the other realms or a special authz-only-realm. The latter is not possible atm because AuthorizingRealms extend AuthenticatingRealm.

It is not hard to create a JWT Authc realm, though. As the Token class is different, login will just skip the JWT realm.

… and there is so much more to it!


Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <[hidden email]>:
Yeah, it seems to be the same indeed.

Regards
JB

> Le 5 avr. 2020 à 13:38, Francois Papon <[hidden email]> a écrit :
>
> I found this one:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> It seems to be the same :)
>
> regards,
>
> François
> [hidden email]
>
> Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> This one?
>>
>> https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md
>>
>> -Brian
>>
>>> On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:
>>>
>>> 
>>> I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔
>>>
>>>> On Sat, Apr 4, 2020, 5:17 PM Brian Demers <[hidden email]> wrote:
>>>> +1
>>>>
>>>> Off the top of my head we have (I'm sure there is more, but ):
>>>>
>>>> * Package name / artifact structure cleanup (breaking change, but minor impact)
>>>> * Remove CAS modules
>>>> * Replace deprecated code (or move to an implementation/private package, for anything still needed)
>>>> * Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
>>>> * Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)
>>>>
>>>> The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
>>>> We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
>>>> That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Sat, Apr 4, 2020 at 8:29 AM Francois Papon <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to start a thread about the next major release: 2.0.0.
>>>>> I think we should move forward on it and only fix bug on the 1.x branches.
>>>>>
>>>>> There is always some issues related to the version in Jira:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>>>
>>>>> We can move also the issues list from the 1.6.0 to the 2.0.0:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12346916
>>>>>
>>>>> I noticed an existing branch about api changes on github:
>>>>>
>>>>> https://github.com/apache/shiro/tree/2.0-api-design-changes
>>>>>
>>>>> I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.
>>>>>
>>>>> Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.
>>>>>
>>>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>>>>
>>>>> We could start a formal vote to validate the plan.
>>>>>
>>>>> Feedback are welcome!
>>>>>
>>>>> regards,
>>>>> --
>>>>> François
>>>>> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

otter606
In reply to this post by Brian Demers
A framework or implementation of standard authorisation server endpoints such as /oauth/token for
standard grant types such as refresh_token, password, authorisation_code etc. e.g described here https://aaronparecki.com/oauth-2-simplified/
Could be a servlet filter, but if so should  delegate to a handler which  can be used in other places e.g. Spring Interceptors, Controllers, standalone applications etc. The Shiro approach of a standard  out-of-the-box implementation with lots of configurable /overridable functionality would work well here, along with reference classes for the various types of token.
E.g. anyone returning JSON of an OAuth token probably has a class similar to this, simple enough but why reinvent the wheel every time.



/**
 * Represents the JSON response returned when refreshing / adding a new OAuth token
 */
@Data
public class NewOAuthTokenResponse {

@JsonProperty("access_token")
private String accessToken;

@JsonProperty("refresh_token")
private String refreshToken;

@JsonIgnore
private Instant expiryTime;
private String scope;

@JsonProperty("token_type")
private static String TOKEN_TYPE = "bearer";

@JsonProperty("expires_in")
public Long expiresIn() {
return Duration. between(Instant. now(), expiryTime).getSeconds();
}

}


On 05 April 2020 at 14:11 Brian Demers <[hidden email]> wrote:

OAuth support has been on the top of my list for a while too! We added a bearer token filter in 1.5, but that is only part of the way there for just one flow.

Anything specific you are looking for? Resource Server? A standard redirect (auth code flow)? OIDC support? etc

-Brian

On Apr 5, 2020, at 7:59 AM, Rob Young <[hidden email]> wrote:

Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams < [hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers < [hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood < [hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--
Rob Young


 
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Brian Demers
In reply to this post by Benjamin Marwell

There are a couple of different items in one

1.) using JWTs to hold authentication data.
How are you minting the original token? are you getting it from a request header (i.e. bearer token)

Thoughts (possibly unrelated) Shiro probably should support some sort of JWT bearer token out of the box similar to support OAuth IdPs that use JWT for access tokens.  (the tricky thing is there is no spec around this so each vendor could be doing something slightly different)

2.) Authorizing vs Authenticating realms 
While this is possible today it probably isn't as easy or as obvious as it could be.
As you mentioned the AuthZ realm extends the AuthC realm.  Right now you can probably do this by creating a custom auth strategy + ModularRealmAuthorizor.
Maybe adding an AuthZ strategy to the ModularRealmAuthorizor would help here? (and providing default implementations so this could be configured with minimal effort)

3.) JWT Authc realm.
I'm really hesitant on making Shiro mint JWTs (except maybe in the case of the RemembeMeManager).  As you mentioned there is a lot around JWTs that need to be considered:

But if you are talking about OAuth2 Resource Server use cases (where Shiro would be validating an JWT), I do think that should be on the table.


You also bring up the point about getting everything out of the authentication token (authz info as well), this is possible today, but again it is less obvious how to do it, and this is NOT an uncommon use case.
This is related to another comment about getting at other attributes from a user.  Maybe a Shiro Subject/PrincipalCollection should hold a set of attributes?

```
Subject.getAttribute("givenName") == "Brian
```

(something similar could be used when building a set of roles:

```
principalCollection.get("groups")
```

Thoughts?


On Mon, Apr 6, 2020 at 2:53 AM Benjamin Marwell <[hidden email]> wrote:
I want to throw in JSON web tokens (JWT).

It is a mess to work with them right now.

JWT can also be very complicated. They can only hold Authentication data, or they can hold roles, or even permission (if it is not getting too long).
I settled to create another realm. If the JWT contains EVERYTHING, the other realms must be skipped (that's the whole point). If it does only contain authc, there must be a possibility to search either the other realms or a special authz-only-realm. The latter is not possible atm because AuthorizingRealms extend AuthenticatingRealm.

It is not hard to create a JWT Authc realm, though. As the Token class is different, login will just skip the JWT realm.

… and there is so much more to it!


Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <[hidden email]>:
Yeah, it seems to be the same indeed.

Regards
JB

> Le 5 avr. 2020 à 13:38, Francois Papon <[hidden email]> a écrit :
>
> I found this one:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> It seems to be the same :)
>
> regards,
>
> François
> [hidden email]
>
> Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> This one?
>>
>> https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md
>>
>> -Brian
>>
>>> On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:
>>>
>>> 
>>> I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔
>>>
>>>> On Sat, Apr 4, 2020, 5:17 PM Brian Demers <[hidden email]> wrote:
>>>> +1
>>>>
>>>> Off the top of my head we have (I'm sure there is more, but ):
>>>>
>>>> * Package name / artifact structure cleanup (breaking change, but minor impact)
>>>> * Remove CAS modules
>>>> * Replace deprecated code (or move to an implementation/private package, for anything still needed)
>>>> * Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
>>>> * Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)
>>>>
>>>> The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
>>>> We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
>>>> That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Sat, Apr 4, 2020 at 8:29 AM Francois Papon <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to start a thread about the next major release: 2.0.0.
>>>>> I think we should move forward on it and only fix bug on the 1.x branches.
>>>>>
>>>>> There is always some issues related to the version in Jira:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>>>
>>>>> We can move also the issues list from the 1.6.0 to the 2.0.0:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12346916
>>>>>
>>>>> I noticed an existing branch about api changes on github:
>>>>>
>>>>> https://github.com/apache/shiro/tree/2.0-api-design-changes
>>>>>
>>>>> I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.
>>>>>
>>>>> Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.
>>>>>
>>>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>>>>
>>>>> We could start a formal vote to validate the plan.
>>>>>
>>>>> Feedback are welcome!
>>>>>
>>>>> regards,
>>>>> --
>>>>> François
>>>>> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Brian Demers
In reply to this post by sreenivas harshith
Agreed Sreenivas,

Do you have a list of specific features you are looking for so we can try to prioritize them?

On Mon, Apr 6, 2020 at 3:56 AM sreenivas harshith <[hidden email]> wrote:
Hi,

Provide native Integrations of pac4j with shiro, jwt , oauth, feature parity with other security frameworks like spring , spring security and others in the .net c# world.





On Mon, Apr 6, 2020 at 12:23 PM +0530, "Benjamin Marwell" <[hidden email]> wrote:

I want to throw in JSON web tokens (JWT).

It is a mess to work with them right now.

JWT can also be very complicated. They can only hold Authentication data, or they can hold roles, or even permission (if it is not getting too long).
I settled to create another realm. If the JWT contains EVERYTHING, the other realms must be skipped (that's the whole point). If it does only contain authc, there must be a possibility to search either the other realms or a special authz-only-realm. The latter is not possible atm because AuthorizingRealms extend AuthenticatingRealm.

It is not hard to create a JWT Authc realm, though. As the Token class is different, login will just skip the JWT realm.

… and there is so much more to it!


Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <[hidden email]>:
Yeah, it seems to be the same indeed.

Regards
JB

> Le 5 avr. 2020 à 13:38, Francois Papon <[hidden email]> a écrit :
>
> I found this one:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> It seems to be the same :)
>
> regards,
>
> François
> [hidden email]
>
> Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> This one?
>>
>> https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md
>>
>> -Brian
>>
>>> On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:
>>>
>>> 
>>> I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔
>>>
>>>> On Sat, Apr 4, 2020, 5:17 PM Brian Demers <[hidden email]> wrote:
>>>> +1
>>>>
>>>> Off the top of my head we have (I'm sure there is more, but ):
>>>>
>>>> * Package name / artifact structure cleanup (breaking change, but minor impact)
>>>> * Remove CAS modules
>>>> * Replace deprecated code (or move to an implementation/private package, for anything still needed)
>>>> * Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
>>>> * Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)
>>>>
>>>> The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
>>>> We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
>>>> That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Sat, Apr 4, 2020 at 8:29 AM Francois Papon <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to start a thread about the next major release: 2.0.0.
>>>>> I think we should move forward on it and only fix bug on the 1.x branches.
>>>>>
>>>>> There is always some issues related to the version in Jira:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>>>
>>>>> We can move also the issues list from the 1.6.0 to the 2.0.0:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12346916
>>>>>
>>>>> I noticed an existing branch about api changes on github:
>>>>>
>>>>> https://github.com/apache/shiro/tree/2.0-api-design-changes
>>>>>
>>>>> I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.
>>>>>
>>>>> Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.
>>>>>
>>>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>>>>
>>>>> We could start a formal vote to validate the plan.
>>>>>
>>>>> Feedback are welcome!
>>>>>
>>>>> regards,
>>>>> --
>>>>> François
>>>>> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Brian Demers
In reply to this post by otter606
Personally I don't think Shiro should implement an Authorization Server,  I think there is room for another project to implement on using Shiro (and Shiro would likely benefit from this). This is actually a major undertaking.  The Spring Security folks tried to drop support for this recently: https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update IIRC, they are still supporting this use case though.

I have a bias opinion on this topic, so someone else please chime in. In most cases, you probably wouldn't want to run your own authorization server, but instead, use a different one KeyCloak if you want to run it yourself, Okta, Microsoft, Google, etc if you don't.

I could be in the minority here, what do others think?



On Mon, Apr 6, 2020 at 4:21 AM Richard Adams <[hidden email]> wrote:
A framework or implementation of standard authorisation server endpoints such as /oauth/token for
standard grant types such as refresh_token, password, authorisation_code etc. e.g described here https://aaronparecki.com/oauth-2-simplified/
Could be a servlet filter, but if so should  delegate to a handler which  can be used in other places e.g. Spring Interceptors, Controllers, standalone applications etc. The Shiro approach of a standard  out-of-the-box implementation with lots of configurable /overridable functionality would work well here, along with reference classes for the various types of token.
E.g. anyone returning JSON of an OAuth token probably has a class similar to this, simple enough but why reinvent the wheel every time.



/**
 * Represents the JSON response returned when refreshing / adding a new OAuth token
 */
@Data
public class NewOAuthTokenResponse {

@JsonProperty("access_token")
private String accessToken;

@JsonProperty("refresh_token")
private String refreshToken;

@JsonIgnore
private Instant expiryTime;
private String scope;

@JsonProperty("token_type")
private static String TOKEN_TYPE = "bearer";

@JsonProperty("expires_in")
public Long expiresIn() {
return Duration. between(Instant. now(), expiryTime).getSeconds();
}

}


On 05 April 2020 at 14:11 Brian Demers <[hidden email]> wrote:

OAuth support has been on the top of my list for a while too! We added a bearer token filter in 1.5, but that is only part of the way there for just one flow.

Anything specific you are looking for? Resource Server? A standard redirect (auth code flow)? OIDC support? etc

-Brian

On Apr 5, 2020, at 7:59 AM, Rob Young <[hidden email]> wrote:

Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams < [hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers < [hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood < [hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--
Rob Young


 
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Benjamin Marwell
In reply to this post by Brian Demers
Hi Brian,

yes, I totally meant VALIDATING a JWT. Absolutely. Not issuing one. That is easy enough for users to implement it theirselves.

JWTs only make sense if they are used:
1. stateless, i.e. no session
2. not as a cookie replacement
3. not as a authz replacement (it should most of the times only carry small authc data)

That said, if a user comes with a bearer token, shiro bears two challenges:
1.) The jwt can easily be validated in the realm, just implement doGetAuthenticationInfo and check issuer, date and signature. That's easy.
2.) If you need to extract authz data, well that's a different problem. if you hit that method, you do not have the key in hand - just look at the method signature: 
    protected AuthorizationInfo doGetAuthorizationInfo(final PrincipalCollection principals)

So you need to store it in a small cache, which does not feel right. Or just look up everything from a 3rd datasource, like your DB.  But then, you can just skip this Realm for the Authc part and have a more general authc strategy.

That said, for multiple realms, just imagine this:
1. Authc via JWT
2. Authc via LDAP
3. Authc via static config file

But for all three realms you want to look up your own database for authorization. You need to implement your own delegator. And I think it is not easy to understand this as a shiro newbie.


Am Mo., 6. Apr. 2020 um 16:26 Uhr schrieb Brian Demers <[hidden email]>:

There are a couple of different items in one

1.) using JWTs to hold authentication data.
How are you minting the original token? are you getting it from a request header (i.e. bearer token)

Thoughts (possibly unrelated) Shiro probably should support some sort of JWT bearer token out of the box similar to support OAuth IdPs that use JWT for access tokens.  (the tricky thing is there is no spec around this so each vendor could be doing something slightly different)

2.) Authorizing vs Authenticating realms 
While this is possible today it probably isn't as easy or as obvious as it could be.
As you mentioned the AuthZ realm extends the AuthC realm.  Right now you can probably do this by creating a custom auth strategy + ModularRealmAuthorizor.
Maybe adding an AuthZ strategy to the ModularRealmAuthorizor would help here? (and providing default implementations so this could be configured with minimal effort)

3.) JWT Authc realm.
I'm really hesitant on making Shiro mint JWTs (except maybe in the case of the RemembeMeManager).  As you mentioned there is a lot around JWTs that need to be considered:

But if you are talking about OAuth2 Resource Server use cases (where Shiro would be validating an JWT), I do think that should be on the table.


You also bring up the point about getting everything out of the authentication token (authz info as well), this is possible today, but again it is less obvious how to do it, and this is NOT an uncommon use case.
This is related to another comment about getting at other attributes from a user.  Maybe a Shiro Subject/PrincipalCollection should hold a set of attributes?

```
Subject.getAttribute("givenName") == "Brian
```

(something similar could be used when building a set of roles:

```
principalCollection.get("groups")
```

Thoughts?


On Mon, Apr 6, 2020 at 2:53 AM Benjamin Marwell <[hidden email]> wrote:
I want to throw in JSON web tokens (JWT).

It is a mess to work with them right now.

JWT can also be very complicated. They can only hold Authentication data, or they can hold roles, or even permission (if it is not getting too long).
I settled to create another realm. If the JWT contains EVERYTHING, the other realms must be skipped (that's the whole point). If it does only contain authc, there must be a possibility to search either the other realms or a special authz-only-realm. The latter is not possible atm because AuthorizingRealms extend AuthenticatingRealm.

It is not hard to create a JWT Authc realm, though. As the Token class is different, login will just skip the JWT realm.

… and there is so much more to it!


Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre <[hidden email]>:
Yeah, it seems to be the same indeed.

Regards
JB

> Le 5 avr. 2020 à 13:38, Francois Papon <[hidden email]> a écrit :
>
> I found this one:
>
> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming
>
> It seems to be the same :)
>
> regards,
>
> François
> [hidden email]
>
> Le 05/04/2020 à 13:32, Brian Demers a écrit :
>> This one?
>>
>> https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md
>>
>> -Brian
>>
>>> On Apr 4, 2020, at 8:28 PM, Les Hazlewood <[hidden email]> wrote:
>>>
>>> 
>>> I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔
>>>
>>>> On Sat, Apr 4, 2020, 5:17 PM Brian Demers <[hidden email]> wrote:
>>>> +1
>>>>
>>>> Off the top of my head we have (I'm sure there is more, but ):
>>>>
>>>> * Package name / artifact structure cleanup (breaking change, but minor impact)
>>>> * Remove CAS modules
>>>> * Replace deprecated code (or move to an implementation/private package, for anything still needed)
>>>> * Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.
>>>> * Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)
>>>>
>>>> The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
>>>> We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
>>>> That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Sat, Apr 4, 2020 at 8:29 AM Francois Papon <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to start a thread about the next major release: 2.0.0.
>>>>> I think we should move forward on it and only fix bug on the 1.x branches.
>>>>>
>>>>> There is always some issues related to the version in Jira:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455
>>>>>
>>>>> We can move also the issues list from the 1.6.0 to the 2.0.0:
>>>>>
>>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12346916
>>>>>
>>>>> I noticed an existing branch about api changes on github:
>>>>>
>>>>> https://github.com/apache/shiro/tree/2.0-api-design-changes
>>>>>
>>>>> I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.
>>>>>
>>>>> Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.
>>>>>
>>>>> It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)
>>>>>
>>>>> We could start a formal vote to validate the plan.
>>>>>
>>>>> Feedback are welcome!
>>>>>
>>>>> regards,
>>>>> --
>>>>> François
>>>>> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Benjamin Marwell
In reply to this post by Brian Demers
Agreed, no oauth server - I was just talking about validating bearer tokens anyway. Didn't mention this, though. Sorry.

Am Mo., 6. Apr. 2020 um 16:40 Uhr schrieb Brian Demers <[hidden email]>:
Personally I don't think Shiro should implement an Authorization Server,  I think there is room for another project to implement on using Shiro (and Shiro would likely benefit from this). This is actually a major undertaking.  The Spring Security folks tried to drop support for this recently: https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update IIRC, they are still supporting this use case though.

I have a bias opinion on this topic, so someone else please chime in. In most cases, you probably wouldn't want to run your own authorization server, but instead, use a different one KeyCloak if you want to run it yourself, Okta, Microsoft, Google, etc if you don't.

I could be in the minority here, what do others think?



On Mon, Apr 6, 2020 at 4:21 AM Richard Adams <[hidden email]> wrote:
A framework or implementation of standard authorisation server endpoints such as /oauth/token for
standard grant types such as refresh_token, password, authorisation_code etc. e.g described here https://aaronparecki.com/oauth-2-simplified/
Could be a servlet filter, but if so should  delegate to a handler which  can be used in other places e.g. Spring Interceptors, Controllers, standalone applications etc. The Shiro approach of a standard  out-of-the-box implementation with lots of configurable /overridable functionality would work well here, along with reference classes for the various types of token.
E.g. anyone returning JSON of an OAuth token probably has a class similar to this, simple enough but why reinvent the wheel every time.



/**
 * Represents the JSON response returned when refreshing / adding a new OAuth token
 */
@Data
public class NewOAuthTokenResponse {

@JsonProperty("access_token")
private String accessToken;

@JsonProperty("refresh_token")
private String refreshToken;

@JsonIgnore
private Instant expiryTime;
private String scope;

@JsonProperty("token_type")
private static String TOKEN_TYPE = "bearer";

@JsonProperty("expires_in")
public Long expiresIn() {
return Duration. between(Instant. now(), expiryTime).getSeconds();
}

}


On 05 April 2020 at 14:11 Brian Demers <[hidden email]> wrote:

OAuth support has been on the top of my list for a while too! We added a bearer token filter in 1.5, but that is only part of the way there for just one flow.

Anything specific you are looking for? Resource Server? A standard redirect (auth code flow)? OIDC support? etc

-Brian

On Apr 5, 2020, at 7:59 AM, Rob Young <[hidden email]> wrote:

Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams < [hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers < [hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood < [hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--
Rob Young


 
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

fpapon
In reply to this post by Brian Demers
Agree, for me Shiro is not the place to implement an Authorization Server, Shiro is more a framework.

regards,
François
[hidden email]
Le 06/04/2020 à 16:40, Brian Demers a écrit :
Personally I don't think Shiro should implement an Authorization Server,  I think there is room for another project to implement on using Shiro (and Shiro would likely benefit from this). This is actually a major undertaking.  The Spring Security folks tried to drop support for this recently: https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update IIRC, they are still supporting this use case though.

I have a bias opinion on this topic, so someone else please chime in. In most cases, you probably wouldn't want to run your own authorization server, but instead, use a different one KeyCloak if you want to run it yourself, Okta, Microsoft, Google, etc if you don't.

I could be in the minority here, what do others think?



On Mon, Apr 6, 2020 at 4:21 AM Richard Adams <[hidden email]> wrote:
A framework or implementation of standard authorisation server endpoints such as /oauth/token for
standard grant types such as refresh_token, password, authorisation_code etc. e.g described here https://aaronparecki.com/oauth-2-simplified/
Could be a servlet filter, but if so should  delegate to a handler which  can be used in other places e.g. Spring Interceptors, Controllers, standalone applications etc. The Shiro approach of a standard  out-of-the-box implementation with lots of configurable /overridable functionality would work well here, along with reference classes for the various types of token.
E.g. anyone returning JSON of an OAuth token probably has a class similar to this, simple enough but why reinvent the wheel every time.



/**
 * Represents the JSON response returned when refreshing / adding a new OAuth token
 */
@Data
public class NewOAuthTokenResponse {

@JsonProperty("access_token")
private String accessToken;

@JsonProperty("refresh_token")
private String refreshToken;

@JsonIgnore
private Instant expiryTime;
private String scope;

@JsonProperty("token_type")
private static String TOKEN_TYPE = "bearer";

@JsonProperty("expires_in")
public Long expiresIn() {
return Duration. between(Instant. now(), expiryTime).getSeconds();
}

}


On 05 April 2020 at 14:11 Brian Demers <[hidden email]> wrote:

OAuth support has been on the top of my list for a while too! We added a bearer token filter in 1.5, but that is only part of the way there for just one flow.

Anything specific you are looking for? Resource Server? A standard redirect (auth code flow)? OIDC support? etc

-Brian

On Apr 5, 2020, at 7:59 AM, Rob Young <[hidden email]> wrote:

Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams < [hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers < [hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood < [hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--
Rob Young


 
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] - Move to 2.0.0

Brian Demers
In reply to this post by Benjamin Marwell
Benjamin,

No worries we are on the same page :)

I absolutely agree with the cache issue between authc and authz.  I've had to work around that a couple times.



On Mon, Apr 6, 2020 at 10:42 AM Benjamin Marwell <[hidden email]> wrote:
Agreed, no oauth server - I was just talking about validating bearer tokens anyway. Didn't mention this, though. Sorry.

Am Mo., 6. Apr. 2020 um 16:40 Uhr schrieb Brian Demers <[hidden email]>:
Personally I don't think Shiro should implement an Authorization Server,  I think there is room for another project to implement on using Shiro (and Shiro would likely benefit from this). This is actually a major undertaking.  The Spring Security folks tried to drop support for this recently: https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update IIRC, they are still supporting this use case though.

I have a bias opinion on this topic, so someone else please chime in. In most cases, you probably wouldn't want to run your own authorization server, but instead, use a different one KeyCloak if you want to run it yourself, Okta, Microsoft, Google, etc if you don't.

I could be in the minority here, what do others think?



On Mon, Apr 6, 2020 at 4:21 AM Richard Adams <[hidden email]> wrote:
A framework or implementation of standard authorisation server endpoints such as /oauth/token for
standard grant types such as refresh_token, password, authorisation_code etc. e.g described here https://aaronparecki.com/oauth-2-simplified/
Could be a servlet filter, but if so should  delegate to a handler which  can be used in other places e.g. Spring Interceptors, Controllers, standalone applications etc. The Shiro approach of a standard  out-of-the-box implementation with lots of configurable /overridable functionality would work well here, along with reference classes for the various types of token.
E.g. anyone returning JSON of an OAuth token probably has a class similar to this, simple enough but why reinvent the wheel every time.



/**
 * Represents the JSON response returned when refreshing / adding a new OAuth token
 */
@Data
public class NewOAuthTokenResponse {

@JsonProperty("access_token")
private String accessToken;

@JsonProperty("refresh_token")
private String refreshToken;

@JsonIgnore
private Instant expiryTime;
private String scope;

@JsonProperty("token_type")
private static String TOKEN_TYPE = "bearer";

@JsonProperty("expires_in")
public Long expiresIn() {
return Duration. between(Instant. now(), expiryTime).getSeconds();
}

}


On 05 April 2020 at 14:11 Brian Demers <[hidden email]> wrote:

OAuth support has been on the top of my list for a while too! We added a bearer token filter in 1.5, but that is only part of the way there for just one flow.

Anything specific you are looking for? Resource Server? A standard redirect (auth code flow)? OIDC support? etc

-Brian

On Apr 5, 2020, at 7:59 AM, Rob Young <[hidden email]> wrote:

Our org uses pac4j for doing oauth and I'd love to drop it, it's one too many security libraries.  It would be fantastic if shiro could provide this natively.

On Sun, Apr 5, 2020 at 7:47 AM Richard Adams < [hidden email]> wrote:
I don't know if this is out of scope, or has been talked about already, but providing some boiler-plate, best-practice standard OAuth2 flows would be good, either for a client getting tokens, or an authorisation server generating tokens. We've been implementing this sort of thing quite a bit ourselves lately, we are no experts but there surely is a need  not to reinvent the wheel every time
On 05 April 2020 at 12:32 Brian Demers < [hidden email]> wrote:

This one? 

https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md

-Brian

On Apr 4, 2020, at 8:28 PM, Les Hazlewood < [hidden email]> wrote:

I wrote a whole wiki page on 2.0 design changes, but I can't find it now 🤔

On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [hidden email]> wrote:
+1

Off the top of my head we have (I'm sure there is more, but ):

* Package name / artifact structure cleanup (breaking change, but minor impact)
* Remove CAS modules
* Replace deprecated code (or move to an implementation/private package, for anything still needed)
* Support javax.annotation.security annotations (or whatever they are now under Eclipse).  These annotations work a little different from the Shiro ones.

* Update to Jakarta dependencies (or figure out a way to work with both, abstracting the HTTP logic), bigger lift (or maybe two different 'web' packages?)

The Jakarta ones have me a little worried though, I think many of the current Shiro users would have a hard time making the switch anytime soon.  Which could kill the adoption of a 2.0.
We could (and probably should) abstract the web specifics out in order to support the _current_ API, Jakarta EE, and other non-servlet stacks (reactive).
That said, it's a likely a bunch of work (and again, I'm guessing most of the user base would use the current API), so this _could_ be a 3.0 item.

Thoughts?






On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < [hidden email]> wrote:
Hi,

I would like to start a thread about the next major release: 2.0.0.
I think we should move forward on it and only fix bug on the 1.x branches.

There is always some issues related to the version in Jira:

https://issues.apache.org/jira/projects/SHIRO/versions/12315455

We can move also the issues list from the 1.6.0 to the 2.0.0:

https://issues.apache.org/jira/projects/SHIRO/versions/12346916

I noticed an existing branch about api changes on github:

https://github.com/apache/shiro/tree/2.0-api-design-changes

I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from tag shiro-root-1.5.2) for maintenance.

Because of some api break, package refactor, deprecated modules or components, we also should start a migration guide in the website.

It's also time for anyone to bring some ideas about the next Shiro features/improvements, feel free to share :)

We could start a formal vote to validate the plan.

Feedback are welcome!

regards,
-- 
François
[hidden email]

 


--
Rob Young