Agree, for me Shiro is not the place to implement an Authorization Server, Shiro is more a framework.
regards, François [email protected] 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 > <[email protected] <mailto:[email protected]>> 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/ > <https://aaronparecki.com/oauth-2-simplified/#authorization> > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 < >>> [email protected] <mailto:[email protected]>> >>> 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 < >>>> [email protected] <mailto:[email protected]>> 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 < >>>>> [email protected] <mailto:[email protected]>> 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 < >>>>> [email protected] <mailto:[email protected]>> >>>>> 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 < >>>>> [email protected] >>>>> <mailto:[email protected]>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> >>> >>> >>> >>> >>> >>> -- >>> Rob Young >>> [email protected] <mailto:[email protected]> >>> > > >
